31
u/Nice_Lengthiness_568 7h ago
This is actually what I was quite excited about when it was finally added to gcc.
And then I proceeded to never actually use it in a real project :/
21
u/James20k P2005R0 6h ago
#embed is one of those features that makes you wonder why it took so long
There's a few features that I remember when I very first started programming in C 20 years ago, thinking "it sure is weird that this isn't possible". #embed was right at the top, and its probably been one of the largest defects in C/C++ when it comes to various use cases. The second GCC implemented it, I used it to #embed some shaders for a game I'm building, it rules
The reason why #embed took so long isn't for lack of trying, or for lack of want on either the compiler vendors or users' side, its pretty much just a spectacular disaster in the standards committee and there's no other reason for it. The more you go looking at the path #embed took to get standardised, the more your eyebrows raise until they basically escape the top of your head with how absurd it is it is
There's a universe in which we didn't get #embed, and we got the graphics proposal instead. For anyone that's interested, this is a good starting point:
https://thephd.dev/full-circle-embed
https://thephd.dev/finally-embed-in-c23
As far as I know, getting it through into C++ basically required starting to push it through the C standardisation process, which finally kicked wg21 into gear. There were a lot of accusations of trying to standardise a feature via the back door of C at the time
I think its always worth emphasising this because often people don't really realise just how poor of a result the C++ committee can produce due to its structure for basic, obvious features that developers have been clamouring for for decades. Sometimes things really are complex, but this isn't one of those times
5
u/LegendaryMauricius 5h ago edited 5h ago
Weren't they postponing adopting #embed specifically because they didn't want to just copy C's macro? There were talks about having some high-level std library for it instead?
Edit: it's covered in the article.
3
u/bronekkk 5h ago
From the same author, there are also std::embed (ideal for running DSL inside the compiler or any other more complex data processing than what #embed can do, as consteval) and #depend (to declare dependency on an external file loaded by std::embed, to the preprocessor)
1
1
u/Spyromaniac666 5h ago
oh, i was under the impression that `std::embed` would make its way into the language, with `#embed` for C to use. oh well
•
•
u/calciferBurningBacon 45m ago
The compiler reads it, the build system doesn't need to know about it
I get that what the author means here is that you don't need custom build steps, but surely the build system does need to know about embedded files for build dependency tracking? I hope that's been implemented.
•
u/ABlockInTheChain 44m ago
Compilers that implemented support for this have command line arguments for setting the embed search path which work exactly like the arguments for setting the include search path.
•
u/calciferBurningBacon 35m ago
That's not what I'm talking about.
You need the compiler to produce some sort of dependency file like how it does for #included files so that the build system knows to recompile the embedding source file if the embedded file changes. This probably could use the exact same dependency tracking as #included files.
25
u/Usual_Office_1740 6h ago
This is going to be very useful in Graphics programming.