
Std::shared_ptr's secret constructor - santaclaus
https://www.justsoftwaresolutions.co.uk/cplusplus/shared-ptr-secret-constructor.html
======
TillE
Interesting, but in most circumstances I think this falls into the "too
clever" category. As with most of C++'s weirder features, you really only want
to use them when you absolutely have to.

std::shared_ptr is already something that should only be used sparingly. Not
because refcounting adds a tiny bit of overhead, but because it can easily
lead to confusion about who owns what. If you use the aliasing constructor,
it's even more confusing.

~~~
nly
The idea is to use shared_ptr when your semantics are such there can be no
clear owner. A good example of this is inside a class where you're
implementing copy-on-write. Imho, you should always endeavour to avoid using
shared_ptr in public APIs. It works especially well where the target is const.

~~~
masklinn
> Good examples of this is inside classes where you're implementing copy-on-
> write.

Or functional "persistent" datastructures.

------
jzwinck
Boost.Python (and Luabind which descends from that) has a similar concept they
call Custodian And Ward. There, an object can extend the lifetime of another
one, often for the same parent and child rationale in this article. It doesn't
come up often in application programming, but in library development it
certainly does.

That said, this constructor is not a secret. It's obscure yet occasionally
useful, like half of C++.

------
cpeterso
So the two shared_ptr instances just share the same (heap-allocated) reference
counter?

------
Rexxar
std::shared_ptr<void> is also very interesting, you can put any object in it
and the destructor will be called when the shared pointer is destroyed.

I never use it until now but I can see some possible use for it.

