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

21–30 of 118 posts

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

#21

Post by jandrewrogers »

tw061023 wrote: post #16
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.

Whip up some kind of in-house IDL/DDL parser, codegen from that. Which, precisely, additions do not fit my points?

Completely inadequate for many use cases. IDL/DDL is one of the least interesting things you could do with reflection in C++. You can already do a lot of that kind of thing with existing metaprogramming facilities.

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

#22

Post by birn559 »

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 has that to do with the topic? Warren Buffet made billions without any do knowledge about programming or deeper knowledge about computers.

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

#23

Post by corysama »

mpyne wrote: post #12
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.

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.

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

#24

Post by tw061023 »

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…

[flagged]

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

#25

Post by birn559 »

tw061023 wrote: post #16
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.

Whip up some kind of in-house IDL/DDL parser, codegen from that. Which, precisely, additions do not fit my points?

Most of the time, I will prefer standard C++ over a full hand made layer of complexity that needs maintenance.

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

#26

Post by tw061023 »

jandrewrogers wrote: post #21
tw061023 wrote: post #16

Earlier quoted context omitted.

Whip up some kind of in-house IDL/DDL parser, codegen from that. Which, precisely, additions do not fit my points?

Completely inadequate for many use cases. IDL/DDL is one of the least interesting things you could do with reflection in C++. You can already do a lot of that kind of thing with existing metaprogramming facilities.

Which use cases? What exactly you can do with "existing metaprogramming facilities"?

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

#27

Post by birn559 »

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…

My perception is that C++XY features are wildly used in general. Of course there are some nobody uses, but that's not generally true. So your basic assumption is wrong.

We are at C++20 and I wouldn't like to work for a company that uses an earlier standard.

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

#28

Post by birn559 »

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.

Do they point at python 3? They were committed to backward compatibility long before python3 happened.

To me it feels like they have fleshed out key paradigms so that is not a mess anymore. They are not there yet with compile time evaluation (constexpr consteval,...), at least with C++20, not sure if it's mostly finished with C++23/26.

The language itself and std is quite bloated but writing modern C++ isn't that complicated anymore in my experience.

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

#29

Post by tw061023 »

birn559 wrote: post #27
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…

My perception is that C++XY features are wildly used in general. Of course there are some nobody uses, but that's not generally true. So your basic assumption is wrong. We are at C++20 and I wouldn't like to work for a company that uses an earlier standard.

Well, either you carefully vet which C++ features you use and my assumption still stands, or you don't - in which case I would rather not like to work in your company.

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

#30

Post by throwaway9832 »

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…

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.

Post reply on HN