Re: [boost] [optional] Reference assignment

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-11-05 08:33:33

Brian McNamara <lorgon_at_[hidden]> wrote:
> On Wed, Nov 05, 2003 at 03:38:37PM +0800, Joel de Guzman wrote:
>> I tried to replace this with Brian's code, but the regression tests
>> failed.  Why?  Because [where o is an optional<T> and v is a T ] *o = v
>> only works when o is initialized, while o = v works even if o is
>> uninitialized.  IOTW, I need this to work:
>> 
>>     match<int> m; // unitialized
>>     m.value(3); // initializes m
>> 
>> So, Brian, to answer your question "So does my code above work for
>> you?", well, unfortunately, not.  I am now inclined to believe that,
>> indeed, "If it ain't broke, don't fix it".  However, in this case, "it"
>> means ***the tried and true C++ reference semantics***.
>> 
>> Thoughts?
> 
> I am a little unclear about the semantics of match, so I need to ask
> some more questions to try to understand it.  Your original use case was
> 
>>     match<T> m(i);
>>     m.value(x); // ok, set the attribute to x
>> 
>>     match<T&> m(r);
>>     m.value(x); // NO, please don't reset the reference, that's not
>>                 // what I want! references should only be set
>>                 // *at construction time*. I want the thing referenced
>>                 // by r set to x.
> 
> and so I didn't realize that match could also have a default
> constructor and hence I didn't forsee this problem.

Right. My mistake. I didn't notice too, until I actually ran the
regressions.

> So we need to also add this use case, I guess:
> 
>>     match<int> m; // unitialized
>>     m.value(3); // initializes m
> 
> Is this:
> 
>>     match<int&> m; // unitialized
>>     m.value(3); // initializes m
> 
> also supposed to be legal?  I am guessing no, (for the same reason that
> you can't say "int& x;") but I am not sure.

No, that's not legal.

> Who actually creates match objects?  The parser?  

Yes.

> When is the default
> constructor called?  (Maybe when a parse fails, but we still need to
> return a match object?)  

Yes.

> When is the non-default constructor called?
> (Maybe when the parse succeeds?)

Yes.

> When is the value(x) method called?  (I have no clue here.)  

Parser-decorators, for example, can call that function anytime post-parse.
For instance, closures set the match's value post-parse:

        template <typename ResultT, typename ParserT, typename ScannerT>
        ResultT& post_parse(ResultT& hit, ParserT const&, ScannerT const&)
        { 
            hit.value(frame[phoenix::tuple_index<0>()]); 
            return hit; 
        }

<< 
hit conforms to the match concept. Perhaps that's why you didn't see in 
the code where a concrete match object is instantiated. It is a concept.
>>

It is possible to have a successful match with an empty attribute (value)
where parser composites can fill in the missing blanks. 

> What is
> its semantics supposed to be?  Does it convert an "empty" match into a
> "full" one?  Or does it just change/update the value of a "full"
> match?  Or both?

<<
Actually, even an empty match can have a valid attribute (e.g. epsilon
match) -- I guess you meant "unsuccessful and successful" match?
>>

The important thing to note that the validity of an attribute of a match 
is not at all related to it's "success". While an unsuccessful match definitely
cannot have a valid attribute, a successful match *can* have an invalid
attribute. This flexibility allows composing parsers to set attributes to
an initially invalid match attribute. To clarify a bit more, here are the
constructors of match:

unsuccessful match, invalid attribute:

    match(); 

successful match, invalid attribute:

    explicit  match(std::size_t length);

successful match, valid attribute:

    match(std::size_t length, ctor_param_t val);

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net