RE: [boost] change to weak_ptr.hpp to compile under Builder C++ 5 , etc

From: Bjorn.Karlsson_at_[hidden]
Date: 2002-05-15 07:48:15

> From: Thomas Witt [mailto:witt_at_[hidden]]
> 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