Re: [Boost-users] Library Interface Design

From: Jens Theisen (jth02_at_[hidden])
Date: 2006-09-14 16:05:09

David Abrahams <dave_at_[hidden]> writes:

> I may totally misinterpreting the question here, but in case I'm
> not...

And I might be misinterpreting the answer, but we probably mean
different things.

You're talking about the rules themselves, are you?

What I want not to be default-constructed is the value that is
constructed by the rule/grammar.

The following is taken from the documentation:

        factor
            =   ureal_p[factor.val = arg1]
            |   '(' >> expression[factor.val = arg1] >> ')'
            |   ('-' >> factor[factor.val = -arg1])
            |   ('+' >> factor[factor.val = arg1])
            ;

I'm not complaining that `factor' must have been default constructed.
I'm worrying about the return value, which is represented by the `val'
closure member. The point where we know what to return is where the
assignments are, but by design we must have some value earlier than
that.

This piece of code is analogous to:

optional< value_t > factor(tokens_t tokens)
{
  value_t ret;

       if(optional< value_t > temp = ureal_p(tokens)) ret = temp;
  else if(optional< value_t > temp = expression(tokens)) ret = temp;
  else ...

  return ret;
}

where one would like to have

optional< value_t > factor(tokens_t tokens)
{
       if(optional< value_t > temp = ureal_p(tokens)) return temp;
  else if(optional< value_t > temp = expression(tokens)) return temp;
  else ...
}

What if value_t is not an int in a calculator example, but, say, a
`binary_expression' object for some programming language parser? Any
default is clearly completely bogus, and I will have to clutter my
program with sanity checks that make sure that I really have a proper
object, as I expect.

Best regards,

Jens