Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++26 Reflections adventures and compile-time UML

reachablecode.com

Post reply on HN
Print view View original

41–50 of 118 posts

Re: C++26 Reflections adventures and compile-time UML

#41

Post by tw061023 »

otabdeveloper4 wrote: post #39
tw061023 wrote: post #6

Earlier quoted context omitted.

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 o…

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.

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.

Re: C++26 Reflections adventures and compile-time UML

#42

Post by jandrewrogers »

lanyard-textile wrote: post #18
lmariscal wrote: post #5

Earlier quoted context omitted.

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.

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 rare…

C++11 was for me the first version of C++ where the expressiveness justified the extra complexity relative to C. It was when I finally committed to using C++ instead of C for systems code. In the same sense, C++20 is qualitatively better than C++11 in every way and dramatically reduces the complexity of C++11 while adding many features C++11 needed.

Re: C++26 Reflections adventures and compile-time UML

#43

Post by comex »

tw061023 wrote: post #19
d_tr wrote: post #15

Earlier quoted context omitted.

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…

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.

Re: C++26 Reflections adventures and compile-time UML

#44

Post by pjmlp »

tw061023 wrote: post #37
pjmlp wrote: post #31

Earlier quoted context omitted.

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

Which problem would this solve for them?

Two language problem, kind of well known issue in engineering tradeoffs.

Re: C++26 Reflections adventures and compile-time UML

#45

Post by dguest »

tw061023 wrote: post #37
pjmlp wrote: post #31

Earlier quoted context omitted.

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

Which problem would this solve for them?

It would standardize something they've done in an ad-hoc way for decades. They have a library called "reflex" [1] which adds some reflection, and which was (re)written by cannibalizing a lot of llvm code. They actually use the reflection to serialize a lot of the LHC data.

It's kind of neat that it works. It's also a bit fidgety: the cannibalized code can cause issues (which, e.g. prevented C++11 adoption for a while in some experiments), and now CERN depends on bits of an old C++ compiler to read their data. Some may question the wisdom of making a multi-billion dollar dataset without a spec and dependent on internals of C++ classes (indeed experiments are slowly moving to formats with a clear spec), but for sure having a standard for reflection is better than the home-grown solution they rely on now.

[1]: https://indico.cern.ch/event/408139/contributions/979831/att...

Re: C++26 Reflections adventures and compile-time UML

#46

Post by Culonavirus »

pjmlp wrote: post #44
tw061023 wrote: post #37

Earlier quoted context omitted.

Which problem would this solve for them?

Two language problem, kind of well known issue in engineering tradeoffs.

As an example, most of the big js/ts ecosystem expansion to the server (RSC/Next/RR7/Expo/...) over the last few years is driven by the wish to have everything under one roof and one language.

People just don't want to maintain two completely different stacks (one on the server, one on the client).

Re: C++26 Reflections adventures and compile-time UML

#47

Post by zozbot234 »

tw061023 wrote: post #6
matt123456789 wrote: post #3

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.

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 o…

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

Re: C++26 Reflections adventures and compile-time UML

#48

Post by oyoman »

dguest wrote: post #45
tw061023 wrote: post #37

Earlier quoted context omitted.

Which problem would this solve for them?

It would standardize something they've done in an ad-hoc way for decades. They have a library called "reflex" [1] which adds some reflection, and which was (re)written by cannibalizing a lot of llvm code. They actually use the reflection to serialize a lot of the LHC data. It's kind of neat that it works. It's also a bit fidgety: the cannibalized code can cause issues (which, e.g. prevented C++11 adoption for a while…

The library that you refer is not in use for a long time already. The document you pointed out is from 2006 (you can check the creation date).

Since then, a lot has changed, and now it is all based on cling ( https://root.cern/cling/ ), that originates from clang and llvm. cling is responsible generates the serialization / reflection of the classes needed within the ROOT framework.

Re: C++26 Reflections adventures and compile-time UML

#49

Post by tw061023 »

comex wrote: post #43
tw061023 wrote: post #19

Earlier quoted context omitted.

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…

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 ca…

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.

Re: C++26 Reflections adventures and compile-time UML

#50

Post by William_BB »

tw061023 wrote: post #24
jandrewrogers wrote: post #20

Earlier quoted context omitted.

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 i…

[flagged]

You sound like you subscribe to "Orthodox C++".

Speaking seriously, I agree there's definitely a lot of bloat in the new C++ standards. E.g. I'm not a fan of the C++26 linalg stuff. But most performance-focused trading firms still use the latest standard with the latest compiler. Just a small example of new C++ features that are used every day in those firms:

Smart pointers (C++11), Constexpr and consteval (all improvements since C++11), Concepts (C++20), Spans (C++20), Optional (C++17), String views (C++17)

Post reply on HN