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

11–20 of 118 posts

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

#11

Post by jcranmer »

d_tr wrote: post #8
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…

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.

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

#12

Post by mpyne »

d_tr wrote: post #8
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…

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

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.

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

#13

Post by rramadass »

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

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

#14

Post by [deleted] »

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…

[deleted]

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

#15

Post by d_tr »

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.

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?

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

#16

Post by tw061023 »

d_tr wrote: post #8
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…

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

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

Which, precisely, additions do not fit my points?

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

#17

Post by mylons »

funkychicken wrote: post #10
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…

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.

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

#18

Post by lanyard-textile »

lmariscal wrote: post #5
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 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 rarely ever a good fit.

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

#19

Post by tw061023 »

d_tr wrote: post #15
jcranmer wrote: post #11

Earlier quoted context omitted.

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

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++ code generator in what, a week? And then polish it from that.

The committee will work for several years, settle on a barely working design, then it will take some years to land in major compilers, then it will turn out it is unusable because someone forgot a key API or it was unfeasible on VAX or something like that.

And my build process is not complicated, and never will be. It can always accomodate another step. Mainly because I don't use CMake.

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

#20

Post by jandrewrogers »

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

Post reply on HN