Boost logo

Boost :

Subject: Re: [boost] [Pointer Container] Modification of pointer containers to allow const elements
From: Gerardo Hernández (g.hernandez_at_[hidden])
Date: 2010-10-15 05:41:55


Scott McMurray <me22.ca+boost_at_[hidden]> wrote:
>>
>> The problem is that the underlying type of boost::ptr_vector<T> is
>> always vector<void*>, no matter T is const.
>>
>
> Since the point of this is to only ever instantiate one version of the
> underlying container, wouldn't it be better to always use
> underlying_container<void const*>, then const_cast when returning to
> the user?

My point was to allow ptr containers of <const T> to work, maintaining
const-correctness. I believe that requires different underlying
container types and not only one as you suggest. So in this code
snippet:

boost::ptr_vector<const int> v;

v.push_back(new int);
v[0] = 3;

the assignment shall produce a compiler error as v[0] would be const,
to maintain const-correctness.

With the underlying type defined as mpl::if_<boost::is_const<T>, const
void*, void*>::type this is accomplished. But using void* const always
as the underlying type and using const_cast during returning (and
inserting) elements, would not const-correctness be lost?

Gerardo.

2010/10/15 Scott McMurray <me22.ca+boost_at_[hidden]>:
> 2010/10/14 Gerardo Hernández <g.hernandez_at_[hidden]>:
>>
>> The problem is that the underlying type of boost::ptr_vector<T> is
>> always vector<void*>, no matter T is const.
>>
>
> Since the point of this is to only ever instantiate one version of the
> underlying container, wouldn't it be better to always use
> underlying_container<void const*>, then const_cast when returning to
> the user?
>
> Since we know we had a pointer to non-const at some point, the
> const_casts would all be legal, afaik.  (const_cast atop an
> underlying_container<void*> would not be.)
>
> ~ Scott
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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