3 ms·
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 (t
by plorkyeran 13y ago
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.
- oddthink 13y agoI'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.
- marshray 13y agoBut 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.