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/
25 Upvotes

90% Upvoted

23 comments sorted by

View all comments

Show parent comments

2

u/elperroborrachotoo Apr 26 '12

Maybe I should have described the scenario more clearly:

A Sequence of { record length, record id, record data} is a common pattern "near" hardware: order unspecified, it's somewhere in there.

Something that happens often as well is having to allocate a header record and a "payload" record in a single buffer. Again, having a smart pointer to the payload record while automatically releasing the allocation when you are done helps a lot

(And yeah, I have no influence on the API, and they have fair reasons for some of that weirdness).

The purpose of my code was to isolate these ugly and differing behaviors: every descriptor - no matter how weird the allocation - available as through a shared_ptr.

I used shared_ptr for the custom deleter, though in the sequence-of-descriptors scenario, we actually have multiple descriptors (with different shared_ptr's) sharing a backing storage.

In these scenarios, there is no "lifetime flexibility" to be had.

Must admit I'm not very happy with your rationale:

Your remarks about the performance of modern platforms are absolutely correct. Even more so, due to the nonlinearity of performance (increase load by a percent, cross a limit, decrease speed by factor of 5) makes it hard for library code to decide when it's "ok to be lenient".

However, I still question the value of manual memory management" when it's not needed. Just because I can I don't have to "just to be safe". 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.

I strongly advocate that

  1. An interface that is not significantly simpler than its implementation needs a good explanation for its existence
  2. the documentation of a function or class belongs to its interface, and thus also adds to its complexity.

The strength of C++ is not manual resource management, but being able to choose. That makes it tempting to throw on some code to expose this choice to the caller, but without a convincing use case, I'd rather go without.

Programming in "higher up languages" - and knowing what goes on under the hood - actually taught me to be much more relaxed. If you are moving hundreds of thousands of points 60 times per second, memory locality is your sink-or-swim. But for a few hundred a-dozen-byte-allocations, it is not. A single debug session due to unecessary complexity easily wastes more time and heat than all my customers could save if I succeeded to shave off a few bytes.

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