Reflection really was the missing piece, it's one of the things that are so nice in Java. Being able to serialize/deserialize a struct to JSON fully dynamically saves a lot of code.
matt123456789 · 3h ago
Whenever I start to feel like a real programmer making games and webapps and AI-enhanced ETL pipelines, I inevitably come across the blog post of a C++ expert and reminded that I am basically playing with legos and play-doh.
tw061023 · 2h ago
It's the other way around. You are the real programmer and the committee and the "modern C++" crowd are more interested playing with legos instead of shipping actual software.
No way anything std::meta gets into serious production; too flexible in some ways, too inflexible in others, too much unpredictability, too high impact on compilation times - just like always with newer additions to the C++ standard. It takes one look at coding standards of real-world projects to see how irrelevant this stuff is.
And like always, the problem std::meta is purported to solve has been solved for years.
jandrewrogers · 1h ago
The stream of modern C++ features have been a god-send for anyone that cares about high-performance, high-reliability software. Maybe that doesn’t apply to your use case but C++ is widely used in critical data infrastructure. For anyone that does care about things like performance and reliability, the changes to modern C++ have largely been obvious and immediately useful improvements. Almost all C++ projects I know in the high-performance data infrastructure space live as close to the bleeding edge of new C++ features as the compiler implementations make feasible.
And no, reflection hasn’t “been solved for years” unless you have a very misleading definition of “solved”. A lot of the C++ code I work with is heavily codegen-ed via metaprogramming. Despite the relative expressiveness and flexibility of C++ metaprogramming, proper reflection will dramatically improve what is practical in a strict and type-safe way at compile-time.
tw061023 · 53m ago
I am sorry, but this reads like GPT.
Which projects? Which features? What exactly was the impact on performance and reliability, how and why? How did critical projects adopt the stream of features, considering nobody sane touches nothing in a new C++ standard for a decade, waiting for DRs to settle and for codegen stopping to suck?
Reflection has been solved for years with custom codegen, including dimensions which std::meta cannot even touch such as stable cross-platform, cross-compiler ABI.
funkychicken · 2h ago
I know the trading firm I work at will be making heavy use of reflection the second it lands… we had a literal party when it made it into the standard.
mylons · 1h ago
sure, but instagram was created by a handful of people with python and got a billion dollar exit in 2012.
birn559 · 57m ago
What has that to do with the topic? Warren Buffet made billions without any do knowledge about programming or deeper knowledge about computers.
throwaway9832 · 18m ago
Every problem is solved. We should stop making anything. Specially CRUD apps, because how is that even programming? What does it solve that hasn't been solved?
This line of thinking is not productive. It is a mistake to see yourself as what you do, because then you're cornering yourself into defending it, no matter what.
d_tr · 2h ago
What's the solution that's been around for years?
> ... just like always with newer additions to the C++ standard.
This is objectively laughable.
mpyne · 2h ago
I was literally running into something a couple of days ago on my toy C++ project where basic compile-time reflection would have been nice to have for some sanity checking.
And even if it's true that some things can be done already with specific compilers and implementation-specific hacks, it would be really nice to be able to do those things more straightforwardly.
My experience with C++ changes has been that the recent additions to compile-time metaprogramming operations is that they improve compile times rather than make it worse, because you don't have to do things like std::enable_if<> hacks and recursive templates to do things that a simple generic lambda or constexpr conditional will do, which are more difficult for both you and the compiler.
corysama · 55m ago
The history of C++ has been one long loop of:
1. So many necessary common practices of C++ are far too complicated!
2. Std committee adds features to make those practices simpler.
3. C++ keeps adding features. It’s too big. They should cut out the old stuff!
4. The std committee points at the decade-long Python 3 fiasco.
5. Repeat.
birn559 · 41m ago
Do they point at python 3? They were committed to backward compatibility long before python3 happened.
To me it feels like they have fleshed out key paradigms so that is not a mess anymore. They are not there yet with compile time evaluation (constexpr consteval,...), at least with C++20, not sure if it's mostly finished with C++23/26.
The language itself and std is quite bloated but writing modern C++ isn't that complicated anymore in my experience.
jcranmer · 2h 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.
d_tr · 1h ago
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?
tw061023 · 1h 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.
birn559 · 47m ago
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.
tw061023 · 34m ago
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.
tw061023 · 1h ago
Whip up some kind of in-house IDL/DDL parser, codegen from that.
Which, precisely, additions do not fit my points?
jandrewrogers · 1h ago
Completely inadequate for many use cases. IDL/DDL is one of the least interesting things you could do with reflection in C++. You can already do a lot of that kind of thing with existing metaprogramming facilities.
tw061023 · 49m ago
Which use cases? What exactly you can do with "existing metaprogramming facilities"?
birn559 · 52m ago
Most of the time, I will prefer standard C++ over a full hand made layer of complexity that needs maintenance.
lmariscal · 3h ago
I would argue that C++ expertise doesn't necessarily correlate to the complexity of the software being developed. Although I do try to learn the fancy new features I know many developers who even though they are still only using C++11 features they are creating some very complex and impactful pieces of software.
lanyard-textile · 1h ago
I definitely think that’s not a coincidence. C++11 is where you get the most useful feature tradeoffs with reasonable costs.
Smart pointers being a great example. Shared ptr has its issues, it isn’t the most performant choice in most cases, but it by far reduces more footguns than it introduces.
Compared to something like std::variant in the C++17 standard that comes with poor enough performance issues that it’s rarely ever a good fit.
tombert · 3h ago
I'm not a C++ developer at all, but unless I'm missing something this didn't seem terribly difficult?
This isn't meant to make myself seem smart or to try and make you seem dumb, I'm just curious what was confusing about this even from a high-level perspective. It felt like a clever but not too atypical metaprogramming thing.
Maybe I've just done too much Clojure.
rramadass · 1h ago
I know your comment was meant as a tongue in cheek funny one but people should not be intimidated/overawed by the size of the C++ feature set. You don't need to know nor use all of them but can pick and choose based on your needs and how you model your problem. Also much of the complexity is perceived rather than real since it takes time for one to understand and assimilate new concepts. You can program very effectively and productively using just C++98 features (along with C if needed) with no hint of "Modern C++" (never mind the fanbois :-) What this gives you is the ability to use a single language to tackle small constrained microcontrollers with very limited toolchain support all the way to using the latest and the greatest toolchain on top-of-line processors.
tombert · 3h ago
I had to do a UML thing for the first time in years for a class a few weeks ago[2].
I'm not 100% convinced that UML is actually useful at all. Obviously if you find value from it, don't let me take that from you, by all means keep doing it, but all it seemed to provide was boxes pointing to other boxes for stuff that really wasn't unclear from looking directly at the code anyway. It's really not that hard to look directly at the class and look directly at the "extends" keyword (or the equivalent for whatever language you're using) and then follow from there. Maybe if you had like ten layers of inheritance it could be valuable, but if you're doing ten layers of inheritance there's a good chance that your code will be incomprehensible regardless.
I'm not against visual diagrams for code, I draw logic out with Draw.io all the time and I've been hacking on the RoboTool [1] toolkit a bit in my free time, but what UML offers always felt more masturbatory than useful.
Maybe I'm wrong, it certainly wouldn't be the first time, but every time I've tried to convince myself to like it I've left a little disappointed. It always kind of felt like stuff the enterprise world does to look like they're working hard and creating value.
No way anything std::meta gets into serious production; too flexible in some ways, too inflexible in others, too much unpredictability, too high impact on compilation times - just like always with newer additions to the C++ standard. It takes one look at coding standards of real-world projects to see how irrelevant this stuff is.
And like always, the problem std::meta is purported to solve has been solved for years.
And no, reflection hasn’t “been solved for years” unless you have a very misleading definition of “solved”. A lot of the C++ code I work with is heavily codegen-ed via metaprogramming. Despite the relative expressiveness and flexibility of C++ metaprogramming, proper reflection will dramatically improve what is practical in a strict and type-safe way at compile-time.
Which projects? Which features? What exactly was the impact on performance and reliability, how and why? How did critical projects adopt the stream of features, considering nobody sane touches nothing in a new C++ standard for a decade, waiting for DRs to settle and for codegen stopping to suck?
Reflection has been solved for years with custom codegen, including dimensions which std::meta cannot even touch such as stable cross-platform, cross-compiler ABI.
This line of thinking is not productive. It is a mistake to see yourself as what you do, because then you're cornering yourself into defending it, no matter what.
> ... just like always with newer additions to the C++ standard.
This is objectively laughable.
And even if it's true that some things can be done already with specific compilers and implementation-specific hacks, it would be really nice to be able to do those things more straightforwardly.
My experience with C++ changes has been that the recent additions to compile-time metaprogramming operations is that they improve compile times rather than make it worse, because you don't have to do things like std::enable_if<> hacks and recursive templates to do things that a simple generic lambda or constexpr conditional will do, which are more difficult for both you and the compiler.
1. So many necessary common practices of C++ are far too complicated!
2. Std committee adds features to make those practices simpler.
3. C++ keeps adding features. It’s too big. They should cut out the old stuff!
4. The std committee points at the decade-long Python 3 fiasco.
5. Repeat.
To me it feels like they have fleshed out key paradigms so that is not a mess anymore. They are not there yet with compile time evaluation (constexpr consteval,...), at least with C++20, not sure if it's mostly finished with C++23/26.
The language itself and std is quite bloated but writing modern C++ isn't that complicated anymore in my experience.
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.
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.
We are at C++20 and I wouldn't like to work for a company that uses an earlier standard.
Which, precisely, additions do not fit my points?
Smart pointers being a great example. Shared ptr has its issues, it isn’t the most performant choice in most cases, but it by far reduces more footguns than it introduces.
Compared to something like std::variant in the C++17 standard that comes with poor enough performance issues that it’s rarely ever a good fit.
This isn't meant to make myself seem smart or to try and make you seem dumb, I'm just curious what was confusing about this even from a high-level perspective. It felt like a clever but not too atypical metaprogramming thing.
Maybe I've just done too much Clojure.
I'm not 100% convinced that UML is actually useful at all. Obviously if you find value from it, don't let me take that from you, by all means keep doing it, but all it seemed to provide was boxes pointing to other boxes for stuff that really wasn't unclear from looking directly at the code anyway. It's really not that hard to look directly at the class and look directly at the "extends" keyword (or the equivalent for whatever language you're using) and then follow from there. Maybe if you had like ten layers of inheritance it could be valuable, but if you're doing ten layers of inheritance there's a good chance that your code will be incomprehensible regardless.
I'm not against visual diagrams for code, I draw logic out with Draw.io all the time and I've been hacking on the RoboTool [1] toolkit a bit in my free time, but what UML offers always felt more masturbatory than useful.
Maybe I'm wrong, it certainly wouldn't be the first time, but every time I've tried to convince myself to like it I've left a little disappointed. It always kind of felt like stuff the enterprise world does to look like they're working hard and creating value.
[1] https://robostar.cs.york.ac.uk/robotool/
ETA:
[2] By "class", I meant like an education class, not a Java class.*