←back to thread

Reflection for C++26

(isocpp.org)
196 points svlasov | 3 comments | 30 Jun 24 11:26 UTC | HN request time: 0.613s | source
Show context
qalmakka ◴[02 Jul 24 06:17 UTC] No.40853995[source]▶
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`?).

replies(5): >>40854017 #>>40854131 #>>40854317 #>>40854746 #>>40854925 #
naertcxx ◴[02 Jul 24 09:36 UTC] No.40854925[source]▶
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.

replies(5): >>40854938 #>>40855245 #>>40856792 #>>40859762 #>>40870787 #
1. Slyfox33 ◴[02 Jul 24 09:40 UTC] No.40854938[source]▶
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.
replies(2): >>40854980 #>>40855316 #
2. naertcxx ◴[02 Jul 24 09:46 UTC] No.40854980[source]▶
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.

3. gpderetta ◴[02 Jul 24 10:50 UTC] No.40855316[source]▶
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.