Boost logo

Boost :

From: Thomas Witt (witt_at_[hidden])
Date: 2002-05-15 06:21:59

Hash: SHA1

On Wednesday 15 May 2002 12:40, Bjorn.Karlsson_at_[hidden] wrote:
> make_shared returns a shared_ptr that may contain a null pointer (thus, the
> resulting shared_ptr should be tested before use). However, if the returned
> shared_ptr contains a valid resource, then that shared_ptr can be safely
> used because the reference count has been increased.

Is it right to say that this is only an issue, if pointers are shared between
threads? AFAICT in a single threaded environment you can safely use a
weak_ptr after testing it.

> That's not true for
> weak_ptr, and that's why make_shared (and the constructor for shared_ptr
> taking a weak_ptr as an argument) adds safety.
> Bjorn Karlsson

The problem I have with this change is that it not only breaks my code but it
breaks my design.

Up to now I have used shared <-> weak ptr to communicate ownership. Shared ptr
implies shared ownership whereas a weak_ptr implies non ownership by the
entity holding the weak_ptr. Think of an object holding a shared_ptr<smth.>
internally and only providing access via weak_ptr. Clients can still stow
away the weak ptr. But the usage of weak_ptr clearly communicates: "Take care
it might go away." and in advantage to bald pointers the client can take care
as he can query the weak ptr about this.

Providing weak -> shared conversion completely breaks this design as clients
can take ownership whenever they like.


- --
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


Boost list run by bdawes at, gregod at, cpdaniel at, john at