Boost logo

Boost :

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-10-20 18:40:26


----- Original Message -----
From: "Juan Carlos Arevalo-Baeza" <jcab.lists_at_[hidden]>

> Also note that, with the typeof extension (or actually researching the complete type, but
that's painful), the skipper_error_parser is not needed:
>
> template < typename ParserT, typename SkipperT >
> typeof(cpp_guard(parser)[skip_error_handler(skipper)])
> error_skipper_p(ParserT const& parser_, SkipperT const& skipper_)
> {
> return cpp_guard(parser)[skip_error_handler(skipper)];
> }
>
> How's that for another reason to keep it? Or even to provide a mechanism, similar to the
proposed "auto" extension, to eliminate the redundancy? I'd propose something like macro functions:
>
> template < typename ParserT, typename SkipperT >
> auto error_skipper_p(ParserT const& parser_, SkipperT const& skipper_)
> = cpp_guard(parser)[skip_error_handler(skipper)];
>
> But I digress...

Since you started it.... The auto and typeof keyword will extremely simplify
the Spirit framework. I imagine a 30..40 % reduction in terms of number of
lines of code.... (And Phoenix/Lambda for that matter).

....no more return type computers...

Also, rules will be obsolete. Consider:

    fwd_rule<1> expression;

    auto group = '(' >> expression >> ')';
    auto factor = integer | group;
    auto term = factor >> *(('*' >> factor) | ('/' >> factor));
    auto start = expression = term >> *(('+' >> term) | ('-' >> term));

... no more scanner/rule business ...

The implication of this is immense. A fully static
"auto" rule will allow aggressive metaprogramming.

--Joel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk