From: Raoul Gough (RaoulGough_at_[hidden])
Date: 2002-05-01 06:06:41
From: "Greg Colvin" <greg_at_[hidden]>
Sent: Tuesday, April 30, 2002 7:53 PM
Subject: Re: [boost] Curaçao: reaction to smart pointer proposal
> At 12:41 PM 04/28/2002, Beman wrote:
> >* LWG members are very concerned that "you don't have to pay for what you
don't use." This is particularly true of memory; increased memory use due to
multiple inheritance or to accommodate weak_ptr, for example, is viewed as a
> I don't really think that is such a big issue, unless shared objects
> are hardly shared at all, and maybe not even then.
> The overhead for the weak pointer need be only one word per object, not
> per pointer, and the smart pointer itself need be only one or two words.
I think the problem is that very few people actually require smart weak
pointers, whereas smart strong pointers are virtually indespensible. Why
should the average user pay a penalty for the requirements of a far narrower
range of users?
There is, however, a fairly simple solution to this problem: by using an
intrusive system for weak pointer support, only those classes that actually
get involved in cyclic reference graphs need include the overhead. I was
actually working on a magazine article about such a scheme, before boost
beat me to it, and the editors thought that the similarities were too great
to warrant publication. If you're interested, the remnants of the article
are at http://myweb.tiscali.co.uk/raoulgough/weak_ptr/. Basically, to be the
target of a weak pointer, an object must allocate a reference-counted
validity flag and promise to clear the flag on destruction. The weak
pointers then each hold a reference to the validity flag, meaning that it
will outlive the original target object if necessary.
One advantage of this scheme is that you can allocate and manage the
target objects any way you like, instead of requiring a particular strong
pointer to control the object lifetime.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk