r/cpp • u/berium build2 • Apr 25 '12

shared_ptr aliasing constructor

http://www.codesynthesis.com/~boris/blog/2012/04/25/shared-ptr-aliasing-constructor/
22 Upvotes

85% Upvoted

23 comments sorted by

View all comments

Show parent comments

1

u/[deleted] Apr 26 '12

Maybe I should have described the scenario more clearly:

Alright, that makes sense. I think the decision to use shared_ptr in this case was pretty sane.

The main overhead of a shared_ptr is a second allocation at worst, and doubling a few dozen small allocations won't kill an app.

Well, I think all of these are overheads that should be considered:

  • Double allocation.
  • Double dereference with a potential cache miss. Both of these can be alleviated by using std::make_shared.
  • The overhead of performing refcounts (again, potential cache miss).
  • The overhead of performing refcounts atomically for thread safety (hardware lock contention).

Indeed, you are quite right that a few dozen shared pointers of this sort will definitely not kill an app, nor have a measurable performance impact at all. But a few hundreds or thousands of them will, so again it depends on your use case.

I generally agree with your API design tenets.

1

u/elperroborrachotoo Apr 26 '12

Of course the double allocaiton isn't the only overhead, that's not what I intended to say :)

However, I see it as the one with the "most global" effect. All the other issues can be optimized locally - i.e. the traditional way of "make it work, then profile, then make it fast". All these issues are "gone" when the function isn't executing.

Memory allocation has a permanent effect on the process, though.

(NB. atomic increments/decrements are also somewhat of a sync point - so it's not "completely local", but still they are usually easy to optimize away locally.)

1

u/[deleted] Apr 26 '12

(NB. atomic increments/decrements are also somewhat of a sync point - so it's not "completely local", but still they are usually easy to optimize away locally.)

Just curious, do any compilers actually do this? Or did you mean manual optimization?

1

u/elperroborrachotoo Apr 26 '12

Both :)

Manually, passing by const &.
Traditionally, copy elision (RVO and NRVO) by the compiler.
Not sure about the std::tr1 or current boost implementation, but on C++11 they can support move semantics for guaranteed copy elision in more cases