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

From: Trevor Perrin (tperrin_at_[hidden])
Date: 2001-03-05 16:07:43

If someone could summarize the conclusions reached by this thread (ie
explain what changes need to be made to get the above const semantics in
VC), I'd much appreciate it!  

-----Original Message-----
From: David Abrahams [mailto:abrahams_at_[hidden]]
Sent: Monday, March 05, 2001 11:22 AM
To: boost_at_[hidden]
Subject: Re: [boost] Re: FW: converting shared_ptr<const T> to
shared_ptr<T>

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

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/