Boost logo

Boost :

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.

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