[boost] Re: shifted_ptr: why?

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2003-10-03 22:03:33

"David B. Held" <dheld_at_[hidden]> wrote in message
news:blkavl$67s$1_at_sea.gmane.org...
> "Powell, Gary" <powellg_at_[hidden]> wrote in message
>
news:16D81990DBE42642A8CA977A55FF116A0BD2E0_at_ex-mail-sea-02.ant.amazon.com...
> > [...]
> > > Of course, I don't have that many compilers to try, either.
> > > Maybe if I had access to some better compilers, I would
> > > get farther.
> >
> > Well the members of boost have access to lot of compilers, so you
> > would get instant feedback. One of the major advantages of boost.
> > Plus as Dave A. mentions there is a lot of porting expertise among
> > the members.
>
> Yes, but you guys make it sound like I've been hiding the code in my
> dungeon.  It's been sitting in the sandbox like a lonely red-headed
> stepchild since I first got access to it.  In fact, I believe at some
> point, I asked people to try it out on other compilers, but it seemed
> that nobody was interested.

Cool. I'm glad about the revived interest, and I'm looking forward to the
time when the insecure lonely red-headed dork will be driving a Beemer and
hanging out with the coolest chicks there are :o). (If I think of it, that's
pretty much what happened to one of smart_ptr's contributors, if you replace
Beemer with Honda and a couple of details here and there.)

So anyway, the upcoming hand-analysis of exception safety in CUJ in December
2003 will be useful to making smart_ptr having a solid definition of what
its exception safety means, and how it depends on the exception safety of
its policies. Figuring out all that for a policy-based design turns out to
be much easier with a framework in mind, and that's why Dave Held and I
threw away a half-written article on smart_ptr alone, to write one that
tries to tackle how exception safety propagates around in the general case.

Another point that we made in the past article is the importance of using
friend functions instead of member functions for primitives. This is because
friend functions "work" whether or not you inherited the object or not,
while member functions don't. Because smart_ptr uses optimally_inherit which
does not inherit a policy unless it holds state, manipulation through
friends becomes not only desirable (as Modern C++ Design argues), but
mandatory. The not-so-good news is that mimicking shared_ptr's usage syntax
might not be 100% doable.

Andrei