Boost logo

Boost :

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

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



Your use of Yahoo! Groups is subject to

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