Re: [boost] Re: FW: converting shared_ptr<const T> to shared_ptr<T>

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-03-04 15:17:45

----- Original Message -----
From: "Ed Brey" <brey_at_[hidden]>

> From: "David Abrahams" <abrahams_at_[hidden]>
> > > Should we make this change to shared_ptr, and then also imbue
> > > shared_array with this functionality (Trevor's example is just as
> > applicable
> > > to arrays)?
> >
> > Careful; this might suddenly also enable the Derived->Base conversion
for
> > arrays, which of course we don't want. You'd have to add some additional
> > BOOST_STATIC_ASSERTs, e.g. for is_same<T, const U> || is_same<T,
volatile
> U>
> > || is_same<T, const volatile U> (since remove_cv doesn't work with VC6).
>
> That seems reasonable, although I'm not familiar with is_same.  Could you
> elaborate on that?

See the type_traits docs. The idea is to make sure that in a conversion from
shared_array<U> to shared_array<T>, T == const U or volatile U or const
volatile U.

A conversion from shared_array<Derived> to shared_array<Base> could easily
cause runtime errors upon destruction.

> I'm also curious about remove_cv.  Given a conforming
> compiler, how would one use that.  The application I have in mind would be
> to put this in shared_array:
>
>  template<typename Y>
>     shared_array(const shared_array<remove_cv T>& r):
>         px(r.px) { ++*(pn = r.pn); }

Won't work with VC6, even after you fix it up as follows:

 template<typename Y>
    shared_array(const shared_array<Y>& r):
        px(r.px) {
BOOST_STATIC_ASSERT((is_same<T,remove_cv<Y>::type>::value)); ++*(pn =
r.pn); }

> where the template parameter Y is just a dummy to force the function to be
a
> member template so that cannot conflict with the copy constructor (on a
> conforming compiler).  But I don't know how to code the remove_cv (or if
> there are other problems with this approach).  If this could be made to
work
> on a conforming compiler, then it could probably also be made to work on
VC
> using the above base class trick.

No, because remove_cv<> doesn't work without partial specialization. Stick
with the is_same approach.

> > > Finally, does anyone know if there are any issues with VC6
> > > silently generating bad code that relate to this situation?
> >
> > I suggest you check the mailing list archives. It's been discussed. I'm
> not
> > saying I'm happy with the current resolution, though ;-).
>
> A search for "silently member templates" brought up a dozen messages, of
> which only http://groups.yahoo.com/group/boost/message/2635 mentioned a
> specific failure mode, which has to do with failing to call a specialized
> function.  There was nothing relating to DLLs.  I couldn't find anything
> concrete to cause one to believe that the shared_ptr workaround won't
work.
> STLport's success with member templates seem to be good precedent upon
which
> to expect success.

Try searching for the subject line "shared_ptr hierarchy question". It's all
there.

-Dave