Boost logo

Boost :

Subject: Re: [boost] [optional] Thoughts on disallowing assignment for wrapped references.
From: Nevin Liber (nevin_at_[hidden])
Date: 2011-09-01 10:19:05


On 1 September 2011 04:28, Mostafa <mostafa_working_away_at_[hidden]> wrote:
>> I see the same thing as all of the other cases, the "exactly 1 time"
>> is relaxed into "0 or more times".
>
> Ahh, I disagree with that.

That may be, but you haven't shown a flaw in my reasoning. I contend
that in the normal lifetime window, both objects and references exist
"exactly 1 time". Where is that reasoning inconsistent?

> IMO, if maybereff was not bound at construction
> time, then it should always remain "uninitialized".

You are arguing for "at most once where lifetime begins at the point
of construction of the optional<U&>"? Why not argue the same for
objects? I don't see the difference, other than you want to introduce
a difference.

>  Now Fernando has made an interesting case for
> why disallowing the assignment operator for optional<T&> and allowing it for
> all other types is bad.

He is arguing for consistency. So am I.

Construction/assignment of an optional<T> is for affecting the
lifetime of the underlying T object it holds. Assignment doesn't
affect lifetime of C++ objects or references, so if one is going to
use that syntax for optional<T>, one has to define what the semantics
should be in both the case where the underlying object or reference
does not yet exist and in the case where the underlying object or
reference already exists.

Assignment to an optional<T> almost models destroying the underlying T
object (if it already exists) followed by creating a new underlying
object. In the case of objects, it performs an optimization by using
assignment instead of destroy/construct in the case where the object
already exists (which is why I said "almost models" in the previous
statement). That optimization does not exist for references.

-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  (847) 691-1404

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