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

From: Ed Brey (brey_at_[hidden])
Date: 2001-03-05 13:38:55

From: "David Abrahams" <abrahams_at_[hidden]>
> > 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
>
> It doesn't. Don't you want to convert shared_ptr<volatile T> to
> shared_ptr<const volatile T>?

I'm not quite sure what you're getting at.  The conversion is fixed by
template types specified in the source and destination shared_ptrs.  The
above isn't converting; it's just filtering what it allowed.  It's
probably not worth going into, though, since it doesn't matter for now,
anyway (see below).  I'm willing to simply accept that I may be
misunderstanding something here (and to be sure, I haven't dealt with
the rules for implicit conversions regarding volatile in a long time, if
ever).

> >, 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 don't buy it, sorry! You will already depend on type_traits, which
is a
> /far/ more complicated library. Also, assertions are good, and I don't
want
> to encourage people to shrink from using them.

I wasn't trying to sell you anything.  I was just stating the tradeoff.
I see that you think that platform-independent code is more important
than eliminating a dependecy on conforming platforms.  I tend to agree
with you.  The static assertion library does have its own caveats due to
its it own compiler bug workarounds, but none seem bad enough that they
are worth the cost of avoiding.

On the other hand, the member-template base class workaround for VC is
one that I think should not be compiled unless necessary.  Even if the
resulting executable is identical, the programmer may see the workaround
if using a tool to view class hierarchies, and it would be valuable for
programmers using conforming compilers not be exposed to this.