Hacker News Reader

Comment by exDM69 | Hacker News Reader

I would say that using a shared_ptr is going the wrong way. A shared_ptr is a reference counter pointer and as such as many shortcomings, such as not being able to do cyclic data structures, being slow, hard to make thread safe. They're also quite complicated and require knowledge of C++ destructors, copycons, RAII, etc to understand.

So, please, don't push shared_ptr as a magic one-size-fits all solution, especially to newbies. There's a reason why reference counting is not used everywhere.

With C++ you must remember that it's using pass-by-value semantics by default, which is very different from pass-by-reference semantics of other (syntactically similar) languages (like Java). Using shared_ptr's will not get rid of this fact and makes things even more complicated.

In fact, I have a very hard time to find _any_ use for shared_ptr's in my C++ projects. scoped_ptr's and ptr_containers have proven to be more useful.

View on HN

Understanding constructors, destructors and RAII is a prerequisite for any real C++ programming. Avoiding shared_ptr for performance reasons before you know it's a bottleneck (it probably isn't) is a premature optimization.

No, I'm not advocating not using shared_ptr's for performance reasons. What I'm trying to say is that reference counting is not a universal solution and it should not be presented as one. It will also add a little bit of complexity to C++ programs and it has some "impedance mismatch" with pass-by-value semantics.

It's as close to a universal solution as you're going to get without a much more intrusive runtime. Obj-C and Python seem to get along just fine with it. I'd say that shared_ptr removes a lot more complexity than it adds in most code. What kind of impedance mismatch do you see with pass-by-value? You should be passing shared_ptr by value.

One of the things I like about C++ is that it gives me choices and I still use raw pointers sometimes but shared_ptr removes a lot of manual memory management noise and makes it much easier to write robust, correct, exception-safe code.

Actually since most if not all CPUs have an atomic increment instruction it is quite easy to make shared_ptr<> thread-safe. In fact, that is what boost::shared_ptr<> does. This makes it a good tool for resources that may be shared between threads or for cases where it's just not worth the mental overhead of worrying about ownership.

That said, shared_ptr isn't a solution to everything. Sometimes scoped_ptr (called unique_ptr in tr1) or intrusive_ptr is a better tool. Often if you don't want to share or transfer ownership, passing around a raw ptr or reference is even better and the only option if you want to work with embedded structs (but the newed memory should still be owned by some RAII smart pointer even if it gets passed around as a bare pointer)

While there are atomic instructions, they usually require memory barriers to ensure modern CPUs order the instructions properly to get the desired behavior. This can have a negative effect on overall performance if these atomic ops are hit in hot spot.

Reply on news.ycombinator.com