Re: Smart pointer status, directions, thoughts

From: williamkempf_at_[hidden]
Date: 2001-05-24 12:46:46

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> 
> > Sometimes it's valid to have less<type> but not operator<(type,
> > type).  Not that this is such a case, but it makes it less likely
> > that a "dangerous precedent" is being set.
> 
> No, it's never valid to have less<type> but not operator<. The only
> exception is for pointers that don't point into the same array.

A)  That's the case here.
B)  Never with an exception?  Good rules don't work this way.
C)  There are plenty of other cases where this holds true.  A classic 
example is std::type_info.  Basically any type that doesn't not have 
full ordering but *can* have consistent partial ordering.

> > > Consider this case:
> > >
> > > shared_ptr<A> pa;
> > > shared_ptr<B> pb;
> > >
> > > Do pa and pb point to the same object? No way to tell without
> > comparing
> > > pa.pn and pb.pn.
> >
> > I don't get this.  Take shared_ptr<> out of the equation and you 
get
> > this:
> >
> > A* pa;
> > B* pb;
> >
> > Do pa and pb point to the same object now?
> 
> I don't know.
> 
> >  If you can figure this
> > out then you can figure it out for shared_ptr<> by using get(), 
and
> > if you can't than shared_ptr<> shouldn't allow you to figure it 
out
> > either.
> 
> shared_ptr is a bit different from a raw pointer. It reperesents 
shared
> ownership. I ask the legitimate question "do pa and pb share 
ownership?"

I don't agree with this, but for some I guess it might be a valid 
view point.  *IF* there's a compelling enough reason to need this 
however, it's still wrong to expose pn.  Instead a same() method (or 
other more suitable name) should be exposed.  I personally still 
don't feel compelled to believe that such functionality should be 
exposed but maybe you can make your case to the owners of shared_ptr.

Bill Kempf