[tw061023]

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]

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.

[SleepyMyroslav]

You are sounding like rose tinted glasses are on. I think your glass is half full if you recheck actual versions and features. And mine is half empty in gamedev.

Anecdata: A year or so ago I have been in discussion if beta features of C++20 on platforms are good to be used on large scale. It makes it not a sum but an intersection of partial implementations. Anyway it looked positive until we needed a pilot project to try. One of the projects came back with 'just flipping C++20 switch with no changes causes significant regression on build times'. After confirming it that it is indeed not an error on our side it was kinda obvious. Proportional increase of remote compilation cloud costs for few minor features is a 'no'. After a year the beta support is no longer beta but still partial on platforms and no improvements on build times in community. YMMV of course because gamedev mostly supports closed source platforms with closed set of build tools.

[MathMonkeyMan]

I still have to learn C++20 concepts and now we have a full-fledged reflection system?

Good, but I think what happens is there are people on the bleeding edge of C++, usually writing libraries that ship with new code. Each new feature is a godsend for them -- it's the reason why the features are proposed in the first place. It allows you to write libraries more simply, more generally, more safely, and more efficiently.

The rest of us are dealing with old code that is a hodgepodge of older standards and toolchains, that has to run in multiple environments, mostly old ones. It's like yeah, this C++26 feature will come in handy for me someday, but if that day comes then it will be in 2036, and I might not be writing C++ by then.

[PartiallyTyped]

I am interested; could you provide some links, articles, etc?

[a_t48]

Prediction: it will be used heavily for things like command line arg parsing, configuration files, deserialization, reflection into other languages. It will probably be somewhat a pain to use, but better than the current alternative mashup of macros/codegen/template metaprogramming that we have now for some of these solutions. It will likely mostly be used for library code, where someone defines some nice utilities for you, that do something useful, so that you don't have to worry about it. I don't think for the most part it has to hurt compile times - it might even be faster than the current mess, as well - less use of templates.

I don't think the "legos" vs "shipping" debate here is really valid. One can write any type of code in any language. I'm a freak about C++, but if someone wants to ship in Python or JS, the more power to them - one can write code that's fast enough to not matter, but takes advantage of those languages' special features.

[funkychicken]

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]

sure, but instagram was created by a handful of people with python and got a billion dollar exit in 2012.

[adev_]

> And like always, the problem std::meta is purported to solve has been solved for years.

It is rare to read something more moronic than that

The Rust equivalent of std::meta (procedural macros) are heavily used everywhere including in serialization framework, debugging and tracers.

And that's not surprising at all: Compile time introspection is much more powerful and lightweight than codegen for exactly the same usage.

[dwroberts]

> It is rare to read something more moronic than that

It's not actually wrong though is it - real codebases have been implementing reflection and introspection through macro magic etc. for decades at this point.

I guess it's cool they want to fix it in the language, but as always, the approach is to make the language even more complex than it already is - e.g. two new operators (!) in the linked article

[germandiago]

I embrace Modern C++, but slower than the committee, when the big three have the feature.

I really think reflection + annotations will give us the chance to have much better serialization and probably something more similar to Python decorators.

That will be plenty useful and it is going to transform a part of C++ ecosystem, for example I am thinking of editors that need to reflect on data structures or web frameworks such as Crow or Drogon, Database access libraries...

[pjmlp]

I bet CERN might eventually replace their Python based code generators with C++26 reflection.

[tw061023]

Which problem would this solve for them?

[zozbot234]

> No way anything std::meta gets into serious production

Rust proc macros get used in serious production, even though they're quite slow to compile. Sure, std::meta is probably a bit clunkier, but that's expected from new C++ features as you say.

[Thom2000]

Sadly, Rust proc macros operate on tokens and any serious macro implementation needs third-party crates.

Compile-time reflection, with good, built in API, akin to C# Roslyn would be a real boon.

[throwaway9832]

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.

[nickysielicki]

> the problem std::meta is purported to solve has been solved for years.

What solution is that? A Python script that spits out C++ code?

[otabdeveloper4]

Yeah, wait till you find out what's behind the curtain in your web engine and AI.

Hint: it's C++, and yes, it will eventually use stuff like std::meta heavily.

[tw061023]

If you would check my comments, you would see I am quite aware. And no, it will not, just like it was with streams, ranges and whatever else.

[d_tr]

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]

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.

[jcranmer]

> 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.

[DLoupe]

For example, boost library's "describe" and similar macro based solutions. Been using this for many years.

[tw061023]

Whip up some kind of in-house IDL/DDL parser, codegen from that.

Which, precisely, additions do not fit my points?

[motorest]

> 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.

I think this is the most clueless comment I ever read in HN. I hope the site is not being hit with it's blend of September.

I was going to explain to you how fundamentally wrong your comment was, but it's better to just kindly ask you to post in Reddit instead.