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

Reflection for C++26

isocpp.org

Post reply on HN
Print view View original

101–110 of 214 posts

Re: Reflection for C++26

#101

Post by naertcxx »

Slyfox33 wrote: post #99
naertcxx wrote: post #98

Earlier quoted context omitted.

I think the focus on smart pointers is a huge mistake. Code bases using shared_ptr inevitably will have cycles and memory leaks, and no one understands the graphs any more. Tree algorithms that are simple in literature get bloated and slow with shared_ptr. The only issue with pointers in C++, which C does not have , is that so many things are copied around by default if one is using classes. So the way to deal with t…

You actually think managing memory manually using new and delete is easier than dealing with occasional problems with leaking memory using shared_ptr? That seems pretty ridiculous to me.

For algorithms like the ones in CLRS, which are explicitly written and proven with pointers in mind, definitely.

As I wrote, the stdlib++ agrees. Read that code and reevaluate your view on whether it is ridiculous.

For other graphs, it depends on the specific application. I am not saying that shared_ptr is always wrong, but often it is.

Re: Reflection for C++26

#103

Post by foldr »

Grayskull wrote: post #86
CuriousCosmic wrote: post #41

Earlier quoted context omitted.

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and kee…

> They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/…

Not really. Even parts of the standard library (e.g. std::variant) more or less require the use of quite advanced language features.

Re: Reflection for C++26

#104

Post by jhasse »

self_awareness wrote: post #67
kstrauser wrote: post #33

I haven't touched C++ since undergrad. Neither have I written any Qt code. But from memory, doesn't Qt's moc implement some of this stuff because it wasn't available in C++? Could this replace moc?

I've always wondered what's the point of "replacing moc". I mean what's the problem with moc? It's required by Qt, and completely transparent by the build system. You don't even know it's used. I mean, GCC also has some helper tools used to compile C++ code and we don't talk about "replacing them". Why people want to remove moc from Qt?

Bugs that come with it.

Re: Reflection for C++26

#105

Post by meindnoch »

maccard wrote: post #97
CuriousCosmic wrote: post #41

Earlier quoted context omitted.

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and kee…

Also that the features c++ is getting are bolt on additions that we already have solutions for. I think fmt is a great example - fmt is a header only library that can be dropped in. Meanwhile std format was standardised without printing to stout. That took 3 years to standardise. Meanwhile we’re working on things like ranges, and instead of implementing them in the language it’s shoe horned in as a library feature -…

>instead of implementing them in the language it’s shoe horned in as a library feature

Quite the opposite. Proliferating the language itself with ad-hoc constructs would be shoe-horning.

Re: Reflection for C++26

#106

Post by meindnoch »

fluoridation wrote: post #38
greenavocado wrote: post #29

Earlier quoted context omitted.

Converting enum values to strings, and vice versa enum class Color { Red, Green, Blue }; template std::string enum_to_string(E value) { constexpr auto enum_info = reflect(E); for (const auto& enumerator : enum_info.enumerators()) { if (enumerator.value() == value) { return std::string(enumerator.name()); } } return "Unknown"; } template E string_to_enum(const std::string& str) { constexpr auto enum_info = reflect(E);…

This is terrible. You can't just do Enum::Member.str or something?

What are you talking about? At runtime, an enum value is just an integer. You need to look up the enum case that corresponds to your integer in order to convert it to a string. Which is precisely what the code above is doing.

Re: Reflection for C++26

#107

Post by account42 »

CuriousCosmic wrote: post #41
stiglitz wrote: post #28

Earlier quoted context omitted.

By ”stagnation” do you mean “not getting new features”?

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and kee…

Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions.

This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to be standardized (or indifinitely - not everything should be added to the stdlib). But even language features can and should exist as compiler extensions before we are stuck with them.

Re: Reflection for C++26

#108

Post by chipdart »

account42 wrote: post #107
CuriousCosmic wrote: post #41

Earlier quoted context omitted.

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and kee…

Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions. This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to…

> There are still too many half-baked ideas that turn out to be mistakes afterwards (...)

Care to point an example?

Re: Reflection for C++26

#109

Post by gpderetta »

account42 wrote: post #107
CuriousCosmic wrote: post #41

Earlier quoted context omitted.

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and kee…

Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions. This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to…

Failed library features at least can be relatively easily deprecated, forgotten and left to rot on the side. Language features will bloat the language almost forever.

One nice advantage of static reflection, macros and other form of program synthesis is that you can experiment with new syntax as a library before committing to integrating it to the base language.

Re: Reflection for C++26

#110

Post by chipdart »

physicsguy wrote: post #74
CuriousCosmic wrote: post #41

Earlier quoted context omitted.

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and kee…

> the people that really care found workarounds Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for.

> Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for.

Some use cases like GUI programming sound like they are better addressed by specialized tech stacks. Nevertheless, either you're talking about greenfield projects or you are hard pressed to find a justification to rewrite a project in another framework. Claiming you stopped writing C++ doesn't fit the bulk of the experience of anyone maintaining C++ projects.

Post reply on HN