Re: [boost] value_initialized<> uploaded to be Files Section.

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-08-27 12:50:21

----- Original Message -----
From: "Darin Adler" <darin_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, August 27, 2002 1:23 PM
Subject: Re: [boost] value_initialized<> uploaded to be Files Section.

>
> On Tuesday, August 27, 2002, at 07:55  AM, Fernando Cacciola wrote:
>
> > This is why I chosen to use const_cast<> instead.
>
> Sadly, const_cast in this case leads to undefined behavior. You can't
> just const_cast to turn an object that was defined as const into
> non-const. You can only use it to strip off const that was added.
>
> So const_cast is not as powerful as mutable. And although you have a
> problem with mutable in this case, using const_cast instead is not the
> solution.
>
> In practice, this arises because C++ implementations are allowed to put
> entirely const objects in read-only areas of memory. The program must
> be told about the mutable member so the implementation knows that it
> might be modified.
>
I see. Thanks for the clarification.

I'll explain my specific problem just in case anyone has a better idea:

value_initialized<T> is a wrapper convertible to T&. So it's basic form
**should be**:

template<class T>
struct W
{
  operator T const& () const { return x ; }
  operator T&          ()          { return x ; }

  T x ;
} ;

Unfortunately, many compilers complain about ambiguity if the conversion
operator is implicitly used as in:

W<int> x ;
( x == 2 ) ;

(See David Abrahams report on which compilers complain)

Thus, I am forced to provide only one operator which has to be the 'const'
one.
This is why I'm forced to leave only:

  operator T& () const { return ... ; }

As for the mutable problem: the only solution I can think of is to resort to
'is_const<>' to select how the data member 'x' is defined in the wrapper.
I've been trying not to do that in order to avoid a dependency with type
traits, for it seems that I can't do without it, after all.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com