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

81–90 of 118 posts

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

#81

Post by motorest »

emmelaich wrote: post #35
mylons wrote: post #17

Earlier quoted context omitted.

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

And Youtube used Python almost exclusively at the start AFAIK. Then again Scott Meyers said he's never written a C++ program professionally.

> Then again Scott Meyers said he's never written a C++ program professionally.

I think you're inadvertently misrepresenting Scott Meyers' claim.

Cited from somewhere else:

> I'll begin with what many of you will find an unredeemably damning confession: I have not written production software in over 20 years, and I have never written production software in C++. Nope, not ever.

He went on to clarify that he made a living out of consultancy, not writing software. He famously retired from C++ in 2015, too.

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

#82

Post by a_t48 »

einpoklum wrote: post #61
a_t48 wrote: post #55

Oh man, some of the code in the linked proposal: Old: template struct list {}; using types = list ; constexpr auto sizes = [] class L, class... T>(L ) { return std::array {{ sizeof(T)... }}; }(types{}); New: constexpr std::array types = {^^int, ^^float, ^^double}; constexpr std::array sizes = []{ std::array r; std::ranges::transform(types, r.begin(), std::meta::size_of); return r; }(); I'm so tired of parameter packs…

But the standard library should have had things so that we can write: constexpr std::array types = {^^int, ^^float, ^^double}; auto sizes = std::whatever::transform(types, std::meta::size_of); which would have been even nicer.

It would have been, but it looks like the difficulty there is that the type of `sizes` must be compile time known, but `std::transform` and friends don't really know about fixed sizes. Depending on the context, one can do `auto sizes = types | std::views::transform(std::meta::size_of);`, the difficulty comes in materializing at the end.

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

#83

Post by a_t48 »

wslh wrote: post #71
a_t48 wrote: post #55

Oh man, some of the code in the linked proposal: Old: template struct list {}; using types = list ; constexpr auto sizes = [] class L, class... T>(L ) { return std::array {{ sizeof(T)... }}; }(types{}); New: constexpr std::array types = {^^int, ^^float, ^^double}; constexpr std::array sizes = []{ std::array r; std::ranges::transform(types, r.begin(), std::meta::size_of); return r; }(); I'm so tired of parameter packs…

This is when I switch to a programming language that doesn't block me from compiling and running just because I forgot some intricate detail. Ironically, I often find assembly programming much friendly. BTW, I continue to maintain some C++ software, and I like cryptopp [1]. I know people now use libsodium. [1] https://github.com/weidai11/cryptopp

I continue to maintain robotics software that nobody uses, such is life. :)

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

#84

Post by ok123456 »

rramadass wrote: post #74
tombert wrote: post #2

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

You have to rethink your view and understanding of UML - https://en.wikipedia.org/wiki/Unified_Modeling_Language It is not just drawing boxes but a visual modeling language providing both static/structural and dynamic/behavioural views of a complete system. You will only understand its value when you actually deal with large systems consisting of many interconnected modules with dependencies. In such large codebases…

In wider practice, UML (class diagrams) is never used by working software developers as a frontend to formal methods.

It got pushed on everyone, so there could be a layer of "software architects" who didn't have to know how to code and could have endless meetings where the final product was a Bayeux Tapestry of UML.

UML captures inheritance and composition well, but a program is more than the sum of its schema. Also, real programming languages all have their idioms, and using UML as the design space creates a significant impedance mismatch.

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

#85

Post by adev_ »

dwroberts wrote: post #75
adev_ wrote: post #73

Earlier quoted context omitted.

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

> 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

> been implementing reflection and introspection through macro magic etc. for decades at this point.

Having a flaky pile of junk as an alternative is never been an excuse to not fix the problem properly.

Every proper modern language (Rust, Kotlin, Zig, Swift, even freaking Golang) has a form of runtime reflection or static introspection.

Only C++ does not. It was done historically with a mess of macros or a pre-compiler (qt-moc) that all have an entire pile of issue.

> the approach is to make the language even more complex than it already is - e.g. two new operators

The problem of rampant complexity in C++ is not so much about the new features when they bring something and make sense.

It is about its inability to remove the old stuff even if it is consensual that it is garbage (e.g iostreams).

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

#86

Post by mikrl »

birn559 wrote: post #22
mylons wrote: post #17

Earlier quoted context omitted.

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

What has that to do with the topic? Warren Buffet made billions without any do knowledge about programming or deeper knowledge about computers.

Mansa Musa was so rich he decreased the local gold to silver exchange rate in Egypt by 12% without ANY modern technology!

https://en.wikipedia.org/wiki/Mansa_Musa#Wealth

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

#87

Post by PartiallyTyped »

jandrewrogers wrote: post #20
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…

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…

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

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

#88

Post by nickysielicki »

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…

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

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

#89

Post by SleepyMyroslav »

motorest wrote: post #77
SleepyMyroslav wrote: post #51

Earlier quoted context omitted.

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…

> One of the projects came back with 'just flipping C++20 switch with no changes causes significant regression on build times'. I think this just proves that your team is highly inexperienced in C++ projects, which you implicitly attest by admitting this was your first C++ upgrade you had to go through. Let me be very clear: there is never an upgrade of the C++ version targeted by a project that does not require full…

I am sorry for the confusion. It's fine to have some downvotes if its not what ppl like to see. I was not complaining. Message was purely informational from single point of view that a) game platforms have only partial C++20 support in 2025. b) there are features that are in C++ standard that do not fit description 'god-send'.

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

#90

Post by MathMonkeyMan »

jandrewrogers wrote: post #20
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…

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…

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.

Post reply on HN