Boost logo

Boost :

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
> > 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,
> 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 =; }

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 =; }

> where the template parameter Y is just a dummy to force the function to be
> 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
> on a conforming compiler, then it could probably also be made to work on
> 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 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
> STLport's success with member templates seem to be good precedent upon
> to expect success.

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at