[boost] Re: Question about smart_ptr

From: David B. Held (dheld_at_[hidden])
Date: 2003-10-08 13:53:47

"Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
news:bm1kcl$ssr$1_at_sea.gmane.org...
> [...]
> Question:
> Would it be possible for the new smart_ptr design to start
> playing around with different architectures (smart_ptr members,
> pointees, etc.)?  Logically speaking, it would require partial
> specializations...?

I'm confused as to whether you are talking about shared_ptr
or smart_ptr.  It looks like you were replying to Peter, who was
talking about shared_ptr, but it looks like here you are talking
about smart_ptr.

> It would be great to specialize the new smart_ptr<T, ...> and
> rename some derivatives to shared_ptr, shifted_ptr, gc_ptr
> (garbage collected raw ptrs w/o reference count), etc.
>
> Dave is that compatible with the new smart_ptr design?

Well, the problem with a specialization, as I understand it, is
that you have to rewrite everything.  After all, isn't that the whole
point of specialization?  If you're going to do that, why not just
go with the original implementations?  The next best thing is
derivation, as Dave A likes to point out.  This is much less
evil than partial spec, because you only have to reproduce
the c'tors (I think...I haven't actually tried it out).  It might be
a worthwhile thing to provide, but right now, there is no set
of existing policies that work with the latest version and
provide emulation for anything besides the original designs
Andrei made.

Whether such policies *could* be written, I don't know, until
somebody tries it.  I don't understand shifted_ptr well enough
to write one myself, although it's been a while since I looked
at it.  I think a pointer that helps collection would be a nice
policy to have, but I don't have a lot of time to write new
policies right now.  In fact, I haven't even been following this
thread very closely, so I don't really know where it's at or
what has been said.  But I think you should try to address
the concerns brought up during the review, especially the
documentation, to help make shifted_ptr stand on its own.
If it can stand on its own, then it might make sense to try to
implement it in terms of smart_ptr.  But to help us out, some
good documentation would help. ;)

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.521 / Virus Database: 319 - Release Date: 9/23/2003