Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-10-24 12:42:58

Rob Stewart wrote:
> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
>> David Abrahams wrote:
>>> Anthony Williams <anthony_w.geo_at_[hidden]> writes:
>> Antony's proposal goes even beyond Sam's idea: rather than dropping
>> assignment from T, we spell it: reset().
>> That is definetly better then direct assignment from T, but I'm not
>> quite sure that is as good a solution as keeping just copy
>> assignment.
>> Consider these 3 versions:
>> int a = 1;
>> int b = 2;
>> int& ra = a ;
>> int& rb = b ;
>> optional<int&> o(ra);
>> *o = rb ; // Clearly doesn't rebind but is UB if 'o' were null.
>> // (1) Current case:
>> o = rb ; // rebind or not??
>> // (2) Antonty's proposal:
>> o.reset(rb); // still some room for doubts?
> That is better because one needs to know its behavior; it's a bit
> harder to assume you know what reset() does than what assignment
> does.
> Your concern that using reset() makes optional look that much
> more like a smart pointer, belying the difference in deep versus
> shallow copying isn't as significant as you make it out to be.
> Not all smart pointers do deep copies and yet reset() is a
> sensible name. Thus, I think reset() is a reasonable name,
> precisely because optional is so much like a smart pointer.
> OTOH, I suggest that reset() take no arguments and only be a
> (the?) way to "unbind" the optional. IOW, rebinding should be
> spelled differently.
So you'd prefer:



o = none


Well, I guess that's depend on what with do with assigment.

If there's only copy assignment, 'o = none' looks consistent.
If there is rebind(), reset() looks consistent.

> As mentioned elsewhere, this won't understand how to deal with
> references versus non-references correctly. You need the user to
> indicate when a reference should really be a reference in the
> optional.
Right, so we need something else.

>> I think (3) spells the actual semantics (rebinding) even more
>> clearly than (2).
>> OTOH, both (2) and (3) are equivalent, so the difference is merely
>> sintatical.
>> Having said that, I prefer (3) which just looks better to my eyes,
>> but (2) could work too.
> I think copy construction is quite obvious and removes the
> (non-)reference confusion of make_optional().
The only problem I see with copy assignment is that it requires you to spell
out the wrapped type; that can be a nuisanse.

Fernando Cacciola

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