Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-21 17:58:17


From: "Fernando Cacciola" <fcacciola_at_[hidden]>

>
> ----- 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.

Sorry I meant operator T const&() const;

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

Really? What's the case that produces it? I don't know a workaround for
that one.

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

Me neither. Not all types are copy-constructible.

> 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.

Nasty. In that case, I defer to whichever choice you think is best. Please
write up the rationale for the docs, though.

Thanks for all your work on this,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com


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