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

141–150 of 214 posts

Re: Reflection for C++26

#141

Post by bluGill »

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

> Can't you just decide to use subset of the language?

That is harder than it sounds. First you have to select which subset to use, it is almost impossible to get any two engineers to agree on that - if you do get agreement that is a bad sign - generally it means the people in the room don't know C++ well enough to make the decision and so you choose the wrong one. The best you can hope for is a compromise where nobody is happy - and thus everyone will look for an excuse to bring in their pet part of C++ not in the subset because there is a "good reason" for an exception.

Even if you select a subset it is almost impossible to enforce whatever subset because even if you don't allow your people to use it directly odds are you bring in a third party library that does use it (the C++ standard library being the big one!)

There are a few exceptions to the above. No exceptions/no RTTI are commonly disabled exceptions and so you will get some compiler and library support. Game companies commonly write their own standard library. Both of these are done for performance reasons and have specific domain specific reasons that can be validated in a profiler to set their rules.

Not related to reflection, but C++26 is also likely to get profiles which will disable specific old constructs, (new/delete) which are proven to be error prone and thus result in security issues. These are a good subset to use, but it is about security and so mostly doesn't get the types of subsets you are talking about.

Re: Reflection for C++26

#142

Post by PathOfEclipse »

chipdart wrote: post #110
physicsguy wrote: post #74

Earlier quoted context omitted.

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

My experience maintaining old codebases is that you are just as hard-pressed to find a justification to write code to use new language features, or even to take the time to upgrade the language and compiler version. Most often you just continue writing code in the same style as the rest of the code base using an old version of the language and runtime.

Re: Reflection for C++26

#143

Post by duped »

aslmq wrote: post #116
account42 wrote: post #111

Earlier quoted context omitted.

shared_ptr isn't the only smart pointer and definitely shouldn't be used for everything. The default should be unique_ptr which is simple to reason about and a huge improvement over only having raw pointers that may or may not be owning what they point to.

unique_ptr is often too restricted. If you have a simple tree with unique_ptr, already the back edges need to be raw pointers to avoid cycles. If you add an iterator, the iterator needs internal pointers to the nodes, so by definition the node pointers are not unique. Again, raw pointers are better. I have never seen a complex data structure where unique_ptr is really used.

You can just not point back to parents (which is rarely needed for anything but iterators) and to not use iterators (since they're a pain in the first place!). The visitor pattern exists for a reason.

Re: Reflection for C++26

#144

Post by lenkite »

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…

Wish C++ fixed some of its mistakes in the standard library. std::regex is embarrassing when even Python can beat it and nobody uses std::unordered_map due to its pointer chasing. Basic Maps are something that you shouldn't need to use a third party library for.

Re: Reflection for C++26

#145

Post by Maxatar »

account42 wrote: post #129
slaymaker1907 wrote: post #61

Earlier quoted context omitted.

You can sort of do it so long as the return type is a template parameter. template T my_construct() { T result; return result; }

That's not polymorphism as that template parameter won't be deduced in any context and you will always have to explicitly instantiate the template.

That is still polymorphic, but as I mentioned C++ does not do the kind of type deduction that Haskell supports so you do have to explicitly instantiate the template. However, you can instantiate it based on context, for example using decltype.

Re: Reflection for C++26

#146

Post by eschneider »

naertcxx wrote: post #98
qalmakka wrote: post #66

While I love this paper and this proposal in general, as a C++ developer every time C++ adds a new major feature I get somewhat worried about two things: 1. how immense the language has become, and how hard it got to learn and implement 2. how "modernising" C++ gives developers less incentives to convince management to switch to safer languages While I like C++ and how crazy powerful it is, I also must admit decades…

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…

Shared pointers are _great_. But, yeah, shared pointers don't _solve_ memory management problems and people still need to understand how pointers work and memory lifetimes. This continues to be hard for a lot of people. :/

Re: Reflection for C++26

#147

Post by ghosty141 »

lenkite wrote: post #144
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…

Wish C++ fixed some of its mistakes in the standard library. std::regex is embarrassing when even Python can beat it and nobody uses std::unordered_map due to its pointer chasing. Basic Maps are something that you shouldn't need to use a third party library for.

Could you explain the issue with unordered_map?

Re: Reflection for C++26

#148

Post by lenkite »

ghosty141 wrote: post #147
lenkite wrote: post #144

Earlier quoted context omitted.

Wish C++ fixed some of its mistakes in the standard library. std::regex is embarrassing when even Python can beat it and nobody uses std::unordered_map due to its pointer chasing. Basic Maps are something that you shouldn't need to use a third party library for.

Could you explain the issue with unordered_map?

The standard guarantees that you can get a pointer to an object in the map and this pointer will remain valid after rehashing and insertion/deletion of other elements. That basically forces implementers to use “buckets with linked lists”, also known as separate chaining. This is not cache friendly (and also suffers from excessive allocation). Other hash map implementations like abseil's don't provide this guarantee so they can put everything right there inline, which is much more efficient.

Re: Reflection for C++26

#149

Post by VHRanger »

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

You can't have faster compile times. If you want fast compile times C++ needs to sacrifice something else (ABI compatibility, compatibility to compile code from 1979 for some dead big endian 12-bit word chip, etc.

In fact the truth is the people working on C++ don't actually value fast compile times over other matters (fast runtime, ABI compatibility, etc.)

They say they do. But they don't in their actions.

One egregious example: look at the compilation speeds of clang with release build configs (-O2 or higher, etc.) over the years.

It compiles much slower now than it did in 2014 for the same code. The compilation speed is worsening at a much faster rate than the runtime speeds are improving from version to version.

Re: Reflection for C++26

#150

Post by AnimalMuppet »

kragen wrote: post #140
AnimalMuppet wrote: post #138

Earlier quoted context omitted.

Partly true. If you're writing library code that someone else might use, you don't have much need to understand the features you don't use, unless you have to handle them at the interface. If you're debugging your own code, you really shouldn't have to understand features that you didn't use. (Mostly - see the next paragraph.) You did say "intentionally". You could wind up using a feature unintentionally, but it's no…

i accidentally used the new implicit constructors for aggregates in c++ the other day, and then my code didn't compile with the version of clang i have installed on my cellphone

LOL. What used to be a typo is now becoming valid syntax (and of course the compiler can't warn you because it's now valid). Ouch. At least an old compiler saved you...
Post reply on HN