Hacker News Reader

Comment by oefrha | Hacker News Reader

> vendor extensions ... were now a legal part of the syntax. If your implementation does not support a thing, it can issue a diagnostic for the parameters it does not understand. This was great stuff.

I can’t be the only one who thinks magic comment is already an ugly escape hatch, adding a mini DSL to it that can mean anything to anyone just makes it ten times worse. It’s neither beautiful nor great.

> do extensions on #embed to support different file modes, potentially reading from the network (with a timeout), and other shenanigans.

(Emphasis mine.) My god.

View on HN

To be completely honest, I find the fact that this was raised by the committee to be really obtuse and unnecessary. The same "complaint" could be raised about #include as well.

If you want to include data from a continuous stream from a device node, then you could just as easily have the data piped into a temporary file of defined size and then #embed that. No need to have the compiler cater for a problem of your own making.

As for the custom data types. It's a byte array. Why not leave any structure you wish to impose on the byte array up to the user. They can cast it to whatever they like. Not sure why that's anything to do with the #embed functionality.

Both these things seem to be massive overthinking on the part of the committee members. I'm glad I'm not participating, and I really do thank the author for their efforts there. We've needed this for decades, and I'm glad it's got in even if those ridiculous extensions were the compromise needed to get it there.

I guess you don't know C.

"#" is not a symbol for a comment line but the one for a pre-processor directive. Like #include stdlib.h

In c/c++ you use // and /* */ for comments.

I’ve known C for close to two decades, thank you. I’m using the not at all well defined term “magic comment” to loosely refer to everything that’s not strictly speaking code but has special meaning, which include pre-processor directives.

cpp is definitely a well-hated part of C.

> I’ve known C for close to two decades, thank you. I’m using the not at all well defined term “magic comment”

Please forgive those of us who've been using C since the 80's, or earlier, from assuming you don't know C when you invent your own terminology for preprocessor directives.

This is not a preprocessor directive though, from reading the post I don’t think cpp is expanding the #embed into an array initializer, otherwise there’s no performance benefit at all.

It's a preprocessor directive. The compiler injects the array based on your instruction.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#a...

The deliberate wording expands #embed to C's initializer-list

The major performance benefit is from the as-if rule. The compiler is entitled to do whatever it wants so long as the result is as-if it worked the way the standard describes.

So a decent compiler is going to notice that you're #embed-ing this in a byte array, and conclude it should just shovel the whole file into the array here. If it actually made the bytes into integers, and then parsed them, they would of course still fit in exactly one byte, because they're bytes, so it needn't worry about actually doing that which is expensive.

Does it work if you try to #embed a small file as parameters to a printf() ? Yeah, probably, go try it on Godbolt (this is an option there) but for the small file where that's viable we don't care about the performance benefit. It's just a nice trick.

Thanks for pointing out the difference, I stand corrected.

The problem with the preprocessor often is that it is a language inside another language and the preprocessor is designed to be almost completely agnostic of the language it is embedded in. So there might be subtle ways to use the preprocessor so that implementing as-if becomes very unintuitive. I don't have a good intuition about this case, if this is 100% designed in a way that it can never provoke such subtle side-effects. Basically what might end up happening is that the preprocessor has to learn some part of the C language to decide if such an as-if transformation is possible and then branch to either do it or don't.

> (Emphasis mine.) My god.

yes, C finally catching up with what languages such as F# have been able to do for years with great success https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/typ... ; wild isn't it to step into the 2010-era of programming ?

I suppose you’re of the opinion that every feature of every language should be added to C, or maybe even assembly.

this isn't adding a new feature. This is replacing a feature that everyone already implemented independently on every other project - some with xxd, some with special embedders such as rcc or windres or whatever, some through CMake directly (like this: https://gist.github.com/sivachandran/3a0de157dccef822a230 for instance) - in a standard and more performant way. Instead of being paid per-project this cost will now be paid per-compiler implementation which is unambiguously good as there are <<< compilers than C projects.

You replied to my quote about pulling network resources and “other shenanigans”, which certainly isn’t what “everyone already implemented independently”. Plus that’s a potential vendor extension, i.e., some may implement it independently, some may not, implementations will likely differ.

> You replied to my quote about pulling network resources and “other shenanigans”, which certainly isn’t what “everyone already implemented independently”.

?? pulling network resources works, today, with what people are using. there's zero difference between "cat foo.txt | xxd -i" and "curl https://my.api/foo.json | xxd -i"

Hell, I #include files mounted over FUSE regularly.

https://github.com/camel-cdr/execfs ?

Reply on news.ycombinator.com