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

51–60 of 118 posts

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

#51

Post by SleepyMyroslav »

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…

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.

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

#52

Post by a_t48 »

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…

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.

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

#53

Post by a_t48 »

jcranmer wrote: post #11
d_tr wrote: post #8

Earlier quoted context omitted.

What's the solution that's been around for years? > ... just like always with newer additions to the C++ standard. This is objectively laughable.

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

I've been down this road. I ended up with a config YAML (basically - an IDL) that goes into a pile of jinja files and C++ templates - and it always ended up better and easier to read to minimize the amount of jinja (broken syntax highlighting, the fact that you are writing meta meta code, it's a hot mess). I'd much prefer to generate some bare structs with some minimal additional inline metadata than to generate both those structs and an entire separate set of structs describing the first ones. std::meta lets me do the former, the latter is what's possible right now.

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

#54

Post by eschneider »

jcranmer wrote: post #11
d_tr wrote: post #8

Earlier quoted context omitted.

What's the solution that's been around for years? > ... just like always with newer additions to the C++ standard. This is objectively laughable.

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

Debugging/modifying code generated from someone's undocumented c++ code generator is pretty close to the top of my list of unpleasant things to do. Yes, you can eventually figure out what to do by looking at the generated code and taking apart the code generator and figuring out how it all works but I'll take built-in language features any day.

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

#55

Post by a_t48 »

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, as useful as they are. Just give me a regular range based for loop or something similar like this. Thank you, this can't come soon enough.

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

#56

Post by ozgrakkurt »

mylons wrote: post #17
funkychicken wrote: post #10

Earlier quoted context omitted.

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.

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

What is this culture of judging everything by amount of money.

No one needs a billion dollars, it is practically irrelevant unless you are running on greed

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

#57

Post by zozbot234 »

corysama wrote: post #23
mpyne wrote: post #12

Earlier quoted context omitted.

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

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.

It's pure Stockholm syndome. There's even a nice C++ committee paper that summarizes this as "Remember the Vasa!" https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0...

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

#58

Post by theICEBeardk »

delusional wrote: post #34

This is interesting because it interacts with consteval. It would be cool if the standards committee could so somehow figure out how to do codegen from consteval. Then we'd be kinda close to the promised land of procedural macros written in real C++.

A lot of the stuff they are working on for c++29 is exactly what you are wishing for (me too by the way).

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

#60

Post by einpoklum »

rramadass wrote: post #13
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.

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

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.

Post reply on HN