Boost logo

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