Re: [boost] Smart pointer status, directions, thoughts

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-05-29 10:36:07

At 10:02 AM 5/29/2001, Greg Colvin wrote:

 >There are also a lot of design tradeoffs -- witness the three
 >or four I have published or proposed over the years, the four or
 >five garbage collectors now in the Boost vault, and the many
 >others in the literature and on the web.
 >
 >Finally, it gets around C++'s lack of metadata by a clever hack
 >with a static variable and cyclic_ptr::operator=(), which hack
 >can be fooled by a common way of writing operator=().  So the
 >following is wrong:
 >
 >   struct X {
 >      cyclic_ptr<Y> p;
 >      ...
 >      X& operator=(const X& x) {
 >         if (&x != this) {
 >            p = x.p;
 >            ...
 >         }
 >         return *this;
 >      }
 >   };
 >
 >The above will prevent the collector from tracing through X::p.
 >Instead you must write something like this:
 >
 >   struct X {
 >      cyclic_ptr<Y> p;
 >      ...
 >      X& operator=(const X& x) {
 >         p = x.p;
 >         if (&x != this) {
 >          ...
 >         }
 >         return *this;
 >      }
 >   };
 >
 >Subtle, and at least one Booster has been burned by it.
 >
 >> Put another way, what do we have to do to mature it to the point where 
we
 >
 >> can make a final keep/abandon decision?
 >
 >Decide whether we can live with the design tradeoffs and the
 >hack.  I'd feel better about the hack if there was a better
 >way to do it coming in the next version of C++.

The design tradeoffs seem reasonable to me, but the hack is quite 
worrisome.  It is clearly error prone.  OTOH, cyclic smart pointers 
shouldn't be sold as anything other that something to meet special needs, 
and requiring special care.

 >Also, decide whether being able to collect cycles is all that
 >important.  We have gotten by with acyclic reference counting
 >pretty well.

Yes, agreed.  To tell the truth, a lot of the other configuration issues 
covered by a configurable (like Andrei Alexandrescu's SmartPtr) smart 
pointer seem more pressing to me.

--Beman