[matt123456789]

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]

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.

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

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

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

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

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

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

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

[lmariscal]

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]

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]

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.

[burnt-resistor]

That's pretty advanced. I realize now I've been finger-painting on the non-washable walls all along. I will now sit in the corner with a dunce cap and consider an execution model for each of greedy and lazy functional languages.

[rramadass]

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.

[einpoklum]

Much of the complexity may be perceived, but much is also real, because of the commitment to backwards compatibility and non-breakage, plus poor default behavior of many things, often due to the C legacy, sometimes due to inopportune choices in earlier versions of the standard. Just think of things like variable initialization with () and/or {} ; or various kinds of implicit casts ; the hoops you need to go through to work with variants; etc.

But I agree that one doesn't have to learn everything, or nearly-everything, to write decent-to-good modern-C++ code.

[mkoubaa]

Library development and application development are activities of a different kind entirely.