|
Boost : |
From: Joel de Guzman (joel_at_[hidden])
Date: 2003-10-31 00:44:37
Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:
> "Brian McNamara" <lorgon_at_[hidden]> escribió en el mensaje
>> do what you want? If T is a reference type, the match's constructor
>> puts the reference in the optional, and then calls to value() change the
>> value of the referred-to object. If T is a non-reference type, it also
>> works, as far as I can tell.
>>
> Maybe the problem is genericity.
> I guess the implementation of 'value()' cannot use the '*' syntax because
> 'data' might be something different than an optional<>.
Well, not really. a match always has 'optional' data. What I am arguing
is that a match<T> is conceptually an optional<T> and hence, the same
reasoning to both classes must apply: i.e. the match<T> use case must
also apply to optional<T>.
> BTW:
> Joel, your use case seems to indicate that the required aliasing semantics
> are actually needed in case 'data' is in fact initialized.
> If I'm right, this would suggest that my recommended semantic for the
> uninitialized lhs case (treat it as initialization) won't conflict with your
> case here.
What I would really like to see is this parallel:
int a = 4;
int& r = a;
r = 3; // a is now 3
<...>
int a = 4;
optional<int&> o(a);
o = 3; // a is now 3
Treating uninitialized lhs as initialization of the reference would
rule out the assignment of constants and literals, right?
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk