> From: Thomas Witt [mailto:witt@ive.uni-hannover.de]
> 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.

Basically, yes. As Peter pointed out, one function call => the pointer may be invalidated, so for safe code (in a single-threaded program, prior to 1.28.0):

weak_ptr<T> wp;

// ...

if(wp.get()!=0)
  wp->f();
if(wp.get()!=0)
  wp->g();
 
> 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.

The design still holds, but without compiler support - if a returned weak_ptr is never "abused", i.e. make_shared is only used for creating temporary shared_ptrs, the design and intent is kept clear.

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

Maybe, maybe not. In this case, someone will (no matter how many lines of comments you write) cache a shared_ptr created from a weak_ptr. Often, that's not a problem - after all, the smart_ptrs are responsible for the lifetime of a resource - but if it breaks the logic of the program, a different design may be needed.

 
Bjorn Karlsson