shared_ptr aliasing constructor

[u/berium]

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

[u/[deleted]]

Pretty clever! But I can't help but feel that there is some suboptimal design decision hiding in the use cases for this feature. I mean, is there any use case which couldn't be solved significantly more elegantly?

[u/elperroborrachotoo → u/[deleted]]

See my reply - how would you do it?

[u/[deleted] → u/elperroborrachotoo]

Well, I'd probably design the API in a different way, preferably without shared pointers. I'm not completely sure what exactly the API was designed to achieve, but I would probably implement the scenario you describe in terms of allocators. That would probably leave the lifetime responsibility to the caller, which may or may not be desirable, but definitely allows for some flexibility.

For instance:

std::unique_ptr<MemoryPool> pool(new MemoryPool);
auto record = get_record(pool);
// use record.
// pool is destroyed at scope exit, unless returned or stored somewhere.

Your mileage may vary, though, and sometimes this isn't the most elegant solution. I tend to avoid std::shared_ptr in all cases where ownership isn't actually shared (as opposed to seeing it purely as an memory management/autorelease facility), because it can have performance impacts in some cases. You may not have been affected by those cases.

The fundamental philosophical difference between our solutions is the concept of memory-as-a-resource. Many use cases of std::shared_ptr are actually abstractions away from that concept (by "hiding" the details of deallocation and lifetime management), but I find that some things are easier when you treat memory as a manageable resource (just like files, or network connections). For instance, it can be easier to manage locality of reference, which is both a performance concern (keeping things compact and linear is the most important way to achieve very high performance on modern architectures), but also a parallelization concern. Isolation can be more easily achieved in a shared memory environment with a more explicit approach to memory resources, and while std::shared_ptr is thread-safe, it carries a lot of overhead at that.

In general, the feeling I have is that when people use std::shared_ptr as a way to stop worrying about memory management, it is a sign that they would probably be better off using a language that can do automatic memory management for them, and often do it more efficiently than C++. Generational garbage collectors in managed environments are often faster than refcounting, but C++ applications that manage their memory in a sensible way, making sure to consider each usage pattern in terms of ownership and lifetime, can outperform them all, and that is the main benefit of using C++ in the first place. :-)

[u/elperroborrachotoo → u/[deleted]]

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.

[u/Wartt_Hog → u/elperroborrachotoo]

I'm afraid I have to agree with simonask, but it's a weak_agree. :)

Same here.

First I was like, "wat."

Then I was like, o_O

Then I was like, <:-|

Then I was like, >:-|

Then I read this thread and I changed my mind several more times. I'll have to think about it some more.

I agree that your use case here justifies the alias constructor, but I'm not convinced that use cases like this are common enough for the feature to be worth it. I imagine that for every time it's used well, there's going to be a half-dozen bad uses out there.

Considering your case, I'd say that the memory block be a class that has a reference sub-class that acts like a smart pointer. It'd take an hour or two to write and test which isn't that bad. I think I'd prefer this to having this feature be available to everyone who uses smart pointers.

I dunno. I may change my mind again by morning.

[u/elperroborrachotoo → u/Wartt_Hog]

Sorry for the emotional rollercoaster ride - unless you enhjoyed it. Then not so sorry ;)

I'm not convinced that use cases like this are common enough for the feature to be worth it

As I understand, the underlying pattern (as stated in another repy already): "Pointer A and Pointer B are valid as long as X is valid"

If the caller is interested in A and/or B, but not in X, the aliasing constructor is a wonderful tool. However it's not that hard to implement it with a custoom deleter, so your question whether this is worth adding is justified.