Hacker News Reader

Comment by oddthink | Hacker News Reader

In every C++ project I've worked on, the vast majority of allocations go immediately into a shared_ptr. This article seems to assert that most C and C++ programs stick to malloc/free or auto_ptr-style semantics. This seems to be a contradiction, so I'm confused. I can see it being true for C, but definitely not for C++.

Am I misunderstanding the thrust of this article?

Edit: deleted comment about cycles, since they are discussed a bit at the end.

View on HN

shared_ptr used to be commonly accepted as a reasonable default choice, but that hasn't been the case for years. unique_ptr/scoped_ptr is nontrivially faster (thread-safe reference counting is fairly expensive), and much less error prone. These days the usual advice is to only use shared_ptr if you absolutely need it.

I'm sure there are many places where other pointer types would be better, but, like I said, I only tend to see shared pointers, usually typecast to something like FooPtr and used indiscriminatly. It's an uphill battle to even use something like a pointer to const.

I've never seen refcounting overhead show up in callgrind, so I think the choice to uniformly use the most general version is OK.

But the insidious thing is they'll be inlined all over the place and may not show up on callgrind. The atomic operations will contribute to cache lock contention inside the processor. Of course it all depends on often you perform operations on the shared_ptrs. Use them only as handles to large components and keep them out of inner loops and you'll be fine.

I suspect he would say that most of the C++ programs you mention don't really need to use shared_ptr, and would be better off with something more like unique_ptr.

Reply on news.ycombinator.com