Reflection for C++26

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 of using it that teaching it to new developers has become immensely hard in the last few years, and the "easier" inevitably ends up being the unsafe one (what else can you do when the language itself tells you to refrain from using `new`?).

Yeah that's because you're not supposed to be using "new" anymore since the introduction of smart pointers in C++11. Std::shared_ptr and std::unique_ptr are preferred. Shared pointers ref count and auto-delete, and unique pointers can't be copied.

While I share the feeling, I don't feel that my daily languages (Java, C#, TypeScript) are getting that far behind.

Even Go is rediscovering that staying simple just doesn't happen for any language that gets industry adoption at scale.

There is no alternative to modernizing C and C++

Indeed I wish they were even more aggressive about breaking changes

Rust is nifty but there is simply too much existing C/C++ out there and "rewrite it in Rust" is not a serious suggestion

Maybe one day we have some cool AI that magically rewrites old C/C++ automatically, but by then I also assume we will have AI-designed languages

Until then, we need C/C++ to be maintained and modernized because we are actually running the world with these languages

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 tree algorithms is to have a hidden tree with pointers and a class that wraps the tree and deletes all dangerous copy methods, implicit and explicit.

stdlib++ seems to use that approach as well.

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.

I agree with this. Python is now more complex than C++. Python looks as if it is simple, because the syntax looks clean.

If you read the new "compilers" [1] in packages like PyTorch, which are unfortunately written in Python, you stare at a huge code base with walls of text, objects calling one another in a maze of ravioli code and generally no help at all to make sense of it all.

Compare that to the gcc code bases, where it is always possible to find some entry point to understand the whole thing.

[1] "compilers", because despite the huge code base (wasn't Python supposed to be terse?) they preprocess the function graph and then call g++ and Triton to do the actual work.

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.

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.

naertcxx point is that you shouldn't use shared_ptr for your next ptr in your list (or other node based container) node. It is slow and error prone. Instead the list container itself should own the nodes and delete them on container destruction. I think it is a good point. unique_ptr is better, but still not always ideal.

I very much have a love/hate relationship with python, but it does have a significantly milder ramp for beginners. The complexity is relatively well hidden. I can recommend python as a first language to someone that wants to learn to program. I can't do that with C++ with a straight face, unless one is especially interested in the areas were C++ still dominates.

Yes, smart pointers don't mean you can entirely stop thinking about ownership and lifetimes but they let you express that ownership in an explicit way with some compiler-enforced protections against mistakes.

> I have never seen a complex data structure where unique_ptr is really used.

What's a "complex" data structure? Anyway, I'd expect to see unique_ptr more in user code rather than in library implementations of data structures where where relatively minor concerns might warrant an ad-hoc implementation even if you could use unique_ptr. In many cases it's probably just that the implementations precede the standardized smart pointers.

Thoughts on Zig? Just not popular enough to fit the bill or are there technical reasons?

I bring it up partially because they are not taking a "rewrite it in Zig" approach, they are specifically aiming for incremental migration in mixed C / Zig codebases.

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.

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

It is always weird to me when people have a big problem with C++ smart pointers but think that Rust smart pointers are the bee’s knees.

It is just a different syntax for the same thing.

I honestly think people just find the words “unique ptr” scary or syntactically overwhelming. If that is true, fortunately we also have using aliases :)

IMO zig is neat but not that much different (for better or for worse) than C and C++. I do really like the comptime concept and wish C had it, and I like it that allocators are explicit in interfaces. There are other things I don’t like about it and I don’t think it has much chance to supplant C or C++.

There are significant differences between the two, even if they are similar at a high level.

But also, pointing out problems doesn’t mean that something is useless. Something can be a net good, yet still have downsides.

Zig is basically Modula-2 for C afficionados, those of us that are confortable with C++ hardly have any benefit from it, those improvements are also on C++ type system.

> The only issue with pointers in C++

There are all sorts of issues with pointers (and not just in C++) - which are inherent to their use. They can point anywhere! They're mutable! They can be null! It's difficult/impossible to ensure they hold a valid value!

Common wisdom is to avoid excessive use of pointers when you don't _really_ need - even smart pointers.

Consider this fine presentation for example:

"Don't use fking pointers" https://klmr.me/slides/modern-cpp/#1

Use references, especially as function parameters,

* Returning values in modern C++ typically does _not_ involve any copying.

* If you want to indicate the possibility that your value is uninitialized/invalid - use std::optional<T>, which can hold either an actual T value or an std::nullopt (being in an "empty" or "value-less" state).

* If your data is in some buffer (or span, or vector etc.), you can use offsets into that buffer.

* Many uses of pointers are due to the "need" to utilize polymorphism: myobj->foo() . Well, typically, you know the real type at compile-time, and can write a freestanding foo() function, which is polymorphic via overloading, or being templated over its parameter's type.

* And speaking of virtual methods and class hierarchies, you can often make do with a template parameter instead of a choice of subclass; or with an std::variant<Foo, Bar>