Re: [boost] [optional] Reference assignment

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-11-05 09:31:41

Wow; thanks for this long and thoughtful response.  It has greatly
clarified my understanding.  I still have a couple of questions, though.

On Wed, Nov 05, 2003 at 09:33:33PM +0800, Joel de Guzman wrote:
> Brian asked:
> > 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; 
>         }

Ah, I see.  Makes sense.
Will the prior value of "hit" necessarily have been a "successful match"?
Will the prior value of "hit" necessarily have a "valid attribute"?

> << 
> 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.
> >>

Indeed!  (So obvious to me now, in retrospect.)

> 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);

Thanks much for this explanation; I had two nearly-orthogonal entities
tangled up together in my mind, and your explanation untangled them.

One more quick question: for this use-case,

> >>     match<int> m; // unitialized
> >>     m.value(3); // initializes m

when does this "happen" in practice?  Maybe in a closure where the first
iteration results in no value but the second iteration does?  I'm still
in the dark, here.

-- 
-Brian McNamara (lorgon_at_[hidden])