Comment by jcranmer
4 days ago
> What's the solution that's been around for years?
Build tools to generate C++ code from some other tool. Interface description languages, for example, or something like (going back decades here) lex and yacc even.
4 days ago
> What's the solution that's been around for years?
Build tools to generate C++ code from some other tool. Interface description languages, for example, or something like (going back decades here) lex and yacc even.
Great. But you can do anything you want by generating code. Why not have a standard solution instead of everyone doing their own, possibly buggy thing complicating their build process even more?
Reframe it as "you can do precisely what you need by generating code" and there is your answer.
Which is far better than to rely on a party which, as I said, has precisely nothing to do with what anyone needs. Which will inevitably produce solutions that can only partially (I am being generous here) be used in any particular situation.
As for "possibly buggy" - look, I can whip up a solid *DL parser complete with a C++ code generator in what, a week? And then polish it from that.
The committee will work for several years, settle on a barely working design, then it will take some years to land in major compilers, then it will turn out it is unusable because someone forgot a key API or it was unfeasible on VAX or something like that.
And my build process is not complicated, and never will be. It can always accomodate another step. Mainly because I don't use CMake.
My perception is that C++XY features are wildly used in general. Of course there are some nobody uses, but that's not generally true. So your basic assumption is wrong.
We are at C++20 and I wouldn't like to work for a company that uses an earlier standard.
1 reply →
You can write a parser for an IDL, but you can’t reasonably write a parser for C++. So you have to move the definition of whatever types of methods or fields you want to reflect on into the IDL, instead of defining them natively in C++. (Or worse, have separate definitions in both the IDL and C++.) Which tends to be cumbersome – especially if you want to define a lot of generic types (since then the code generator can’t statically determine the full list of types). It can work, but there’s a reason I rarely see anyone using this approach.
1 reply →
Debugging/modifying code generated from someone's undocumented c++ code generator is pretty close to the top of my list of unpleasant things to do. Yes, you can eventually figure out what to do by looking at the generated code and taking apart the code generator and figuring out how it all works but I'll take built-in language features any day.
I've been down this road. I ended up with a config YAML (basically - an IDL) that goes into a pile of jinja files and C++ templates - and it always ended up better and easier to read to minimize the amount of jinja (broken syntax highlighting, the fact that you are writing meta meta code, it's a hot mess). I'd much prefer to generate some bare structs with some minimal additional inline metadata than to generate both those structs and an entire separate set of structs describing the first ones. std::meta lets me do the former, the latter is what's possible right now.