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

From: Ed Brey (brey_at_[hidden])
Date: 2001-03-05 09:54:04

From: "David Abrahams" <abrahams_at_[hidden]>
> > 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.

Thanks for the pointer.  I have not followed the type_traits discussion nor
looked at the library, and when I grepped for remove_cv within boost I
accidentally specified a wrong directory that only contained a subset of
boost, and so was simply ignorent of what you were referring to.  (I thought
maybe by remove_cv you were referring to some secret corner of C++ that I
wasn't aware of.)  Now things are clear.

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

Absolutely.  My only question was regarding your new-to-me techniques for
detecting this.

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

My intention was to point out a possible solution that avoids use of static
assertions when used on conforming compilers.  Using proper type_traits
notaion, the shared_array member template would look like this:

template<typename Y>  // Note that Y is a dummy.
  shared_array(const shared_array<remove_cv<T>::type>& r):
  px(r.px) { ++*(pn = r.pn); }

Assuming that this works, then the question becomes "Is there any value in
avoiding a static assertion?"  It avoids the dependency on the static
assertion library and just seems a little cleaner to only allow in what one
wants rather than allow too much and then check for correctness.

I realize that this method won't work for VC6, due to lack of partial
specialization.  For VC6, your proposed is_same workaround seems like the
way to go.  It's up to the library maintainer whether the preference is to
use as common of code as possible, versus use ideal world code when possible
replaced by workarounds as needed for broken compilers, so long as the
result is the same.  Here the result is very nearly the same, differing only
in a library dependency that would unnecessarily exist on a conforming
platform if it shared code that required the dependency to work on a
non-conforming platform.

> > > > Finally, does anyone know if there are any issues with VC6
> > > > silently generating bad code that relate to this situation?
> > [ A search for "silently member templates" yielded no fruit. ]
> Try searching for the subject line "shared_ptr hierarchy question". It's
all
> there.

That discussion seemed to never be concluded, left with "member templates
break DLL exporting" versus "STLport seems to handle it some how" (my
wording: see http://groups.yahoo.com/group/boost/message/5932 for original).
I don't know the answer to this question.