Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-03-05 14:22:24


----- Original Message -----
From: "Ed Brey" <brey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, March 05, 2001 1:38 PM
Subject: Re: [boost] Re: FW: converting shared_ptr<const T> to shared_ptr<T>

> 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).

It's simple: remove_cv<const volatile T>::type is plain T, so you won't
generate a conversion from shared_array<const T> or shared_array<volatile T>
to shared_array<const volatile T>. Only shared_array<T> will be convertible
to shared_array<const volatile T>

> 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.

I disagree: it's an implementation detail. The more #ifdefs we can remove
from the code, the better it will survive maintenance.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk