Re: [boost] value_initialized<> utility template

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-08-21 17:28:46

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, August 21, 2002 6:49 PM
Subject: Re: [boost] value_initialized<> utility template

> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
>
> >
> > [snipped]
>
> Yeah, but in case (B):
>
>     value_initialized<int> const cx;
>     int& x = cx;
>     x = 1;
>
Yes, I noticed this.

> why don't you do something like:
>
>     operator T const() const;
>
> in the case where T is non-const? You just need to dispatch to one of 2
> implementations for this, depending on T's const-ness.
>
But this returns a *copy* of the wrapped object. Is this what you want? I
know *I* don't want it.

I initially used a dispatch upon T's const-ness.
The const-T case is trivial,
but the 'non-const' T suffers from this: both operators cannot be provided
because they yield ambiguity:

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

Of course, returning a copy, as you suggested solves the problem, but I
don't entirely like it.

Therefore, I removed the dispatch since it didn't bring any real benefits.

I've though about this for a while and concluded that the pathological
behavior shown above would not be so much of a problem in practice if the
program is properly formed. That is, a decent programmer can always make
sure not to modify const objects. If we could prevent that with zero-cost,
then we'll do it, but the alternative, AFAICT, is to introduce the copy
overhead just to trap this sort of misuse.

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