Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-02-09 09:05:30
On Thu, Feb 9, 2012 at 5:39 PM, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
> First, let me show why opt = nval; is controversial.
I understand and agree that opt = nval may be ambiguous and even dangerous.
> I lean towards disabling opt = opt because it is
> very similar to opt = nval;
> int i = 1;
> int j = 2;
> optional<int&> oi = i;
> optional<int&> oj = j;
> i = j;
> The effect here is that i remains 1, j remains 2 and oi and oj both hold a
> reference to j. You may find it less surprising but if you think of
> optional reference as a regular reference that is initialized a bit later,
> the behavior is not what you would expect.
I see your point but, IMHO, optional<T&> is too different from normal
references to attempt to draw this association. After all,
optional<T&> is an object in the sense it has internal state and you
can take its address while T& is not (one may call it an alias of an
object). It is therefore logical that optional<T&>::operator= operates
on the object (i.e. on the optional contents) and hypothetical
T&::operator= operates on the referred object.
> Note that if you store a normal reference to int as class member, you
> already have to write your assignment yourself. changing a normal reference
> to an optional reference should not come as something irregular.
Again, I tend to see optional<T&> as an object, with no apparent
reason why it cannot be assigned to.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk