Comment by tw061023
4 days ago
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.
Well, either you carefully vet which C++ features you use and my assumption still stands, or you don't - in which case I would rather not like to work in your company.
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.
Why would I want to write a C++ parser?
IDL/DDL is the source of truth, moving the type definitions there is the whole point. There is only one definition for each type, which is in the *DL, corresponding C++ headers are generated and everything is statically known.