[naertcxx]

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.

[account42]

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.

[aslmq]

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.

[binary132]

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 :)

[steveklabnik]

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.

[einpoklum]

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

[Slyfox33]

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.

[gpderetta]

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.

[naertcxx]

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.

[eschneider]

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