6 ms·
> told me this form was non-ideal and it was worth voting against (and that they’d want the pure, beautiful C++ version only[1]) I heard about #embed, but I di
by yakubin 4y ago
> told me this form was non-ideal and it was worth voting against (and that they’d want the pure, beautiful C++ version only[1])
I heard about #embed, but I didn't hear about std::embed before. After looking at the proposal, to me it does look a lot better than #embed, because reading binary data and converting it to text, only to then convert it to binary again seems needlessly complex and wasteful. I also don't like that it extends the preprocessor, when IMHO the preprocessor should at worst be left as is, and at best be slowly deprecated in favour of features which compose well with C proper.
Going beyond the gut reaction and moving on to hard data, as you can expect from this design, std::embed of course is faster during compilation than #embed for bigger files (comparable for moderately-sized files, and a bit slower for tiny files).
I'm not a huge fan of C++, but the fact that C++ removed trigraphs in C++17 and that it's generally adding features replacing the preprocessor scores a point with me.
[1]: <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1040r6.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p10...>
- twoodfin 4y agoI don’t think the implication is that the C compiler must encode the binary file as a comma-separated integer list and then re-parse it, only act as if it did so.
- yakubin 4y agoHow would that work? It would need to depend on the grammar of surrounding C code. This directive isn't limited to variable initialisers. You can use it anywhere. So e.g. you can use it inside structure declaration, or between "int main()" and "{". etc. etc. Those will generate errors in subsequent phases, but during preprocessing the compiler doesn't know about it. Then there is also just that: int main () { return #embed "file.bin" ; } There are plenty of cases, where it will all behave differently. And if you're going to pretend even more that the preprocessor understands C syntax, then why not just give this job to compiler proper, which actually understands it?
- deleted 4y ago[deleted]
- defen 4y agoPreprocessing produces a series of tokens, so you would implement it as a new type of token. If you're using something like `-E` you would just pretty-print it as a comma-delimited list of integers. If you're moving on to translation phase 7, you'd have some sort of rules in your parser about where those kinds of tokens can appear . Just like you can't have a return token in an initializer, you wouldn't be allowed to have an embed token outside of one (or whatever the rules are). And you can directly instantiate some kind of node that contains the binary data.
- GrumpySloth 4y ago> you would implement it as a new type of token That's a good point. I consider myself debunked.
- deleted 4y ago[deleted]
- mgaunard 4y agothe preprocessor is a great tool to reduce duplication and boilerplate. People that don't like it generally just don't know how to use it.
- timhh 4y agoPeople don't dislike it because they are unaware how helpful it can be. They dislike it because they are aware how hacky, fragile and error-prone it is. They want something more robust than text substitution.
- LadyCailin 4y agoOr perhaps those people can think of better ways to get those benefits that also don't allow things like #ifndef asdf }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} #endif which obliterate tooling such as IDEs. Of course, this is a contrived example, but the preprocessor is just one big footgun, which offers no benefits over other ways of solving the problems you mentioned, such as constexpr and perhaps additional, currently unimplemented solutions.
- mgaunard 4y agoIt being possible to misuse a tool does not mean the tool is not very useful.
- KerrAvon 4y agoA tool being very useful doesn’t mean that it is a very good tool. There are better tools for the functionality the C preprocessor attempts to provide. Other languages have module inclusion systems and very powerful macros that don’t have the enormous footguns of the C preprocessor. Édit: to be clear, I think #embed is a fine idea; I’d use it and it would make my sourcebase cleaner in some places.
- makapuf 4y agoMy carpenter has a lot of tools that can be dangerous if misused. Of course better tools can be devised, but useful things have been done with them (and he still has all his fingers)
- colonwqbang 4y agoCompilers follow the "as if" principle, they don't have to literally follow the formal rules given by the standard. They could implement #embed by doing as you say, pretty printing out numbers and then parsing them back in again. But that would be an extremely roundabout way to do it, so I doubt anyone will actually do it that way. Unless you're running the compiler in some kind of debugging mode like GCC's -E.