Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2002-01-22 15:49:43


-----Original Message-----
From: Vladimir Prus <ghost_at_[hidden]>
To: boost_at_[hidden] <boost_at_[hidden]>
Date: Monday, January 21, 2002 05:50 AM
Subject: [boost] Command line syntaxes

>[...]
>I'd like to ask that we don't start "Spirit vs. hand-make parser"
discussion
>once again.
>[...]

20 minutes later, Vladimir writes...

>HartmutKaiser_at_[hidden] wrote:
>> Vladimir Prus wrote:
>> > "-bar" can be interpreted, depending on the styles user wants
>> > as either:
>> > 1) Three short options
>> > 2) Short option followed by parameter
>> > 3) Long option
>> > Can you give an *example* of how this can be handled with Spirit.
>>
>> char const *option_to_parse = "-your_option_here";
>> char const *end_of_option = option_to_parse+strlen(option_to_parse);
>>
>> // 1) Three short options
>[snip]
>> // 2) Short option followed by parameter
>[snip]
>> // 3) Long option
>[snip]
>
>And how do I specify that "-xy" should be treated as two options when 'x'
>takes no parameter and as an option with parameter otherwise? How will I
>detect the case when there short option "f" and there's long option "foo",
in
>which case "-f" can mean either the short option or the abbreviated long
one?

Am I the only person that detects an inconsistency here?

To answer the questions posed, and only the questions, I present:

1) -x takes no parameter:

rule<> cla =
    lexeme[
        chlit('-') >> +(
        chlit('x')[&handle_option_x] |
        chlit('y')[&handle_option_y]
    )];

2) -x takes one parameter:

rule<> cla =
    *(
        strlit("-x") >> lexeme[*(anychar - ' ')][&handle_x_param] |
        strlit("-y")
    );

3) -x takes a parameter iff -b has already been encountered as an
option:

rule<> x_no_param =
    lexeme[
        *(
            *chlit(' ') >> chlit('-') >>
            +(
                chlit('x')[&handle_option_x] |
                chlit('y')[&handle_option_y] |
            ) >>
        ) >>
        +(
            chlit('b')[&handle_option_b] |
            chlit('y')[&handle_option_y]
        )
    ];

rule<> x_param =
    lexeme[
        *(
            *chlit(' ') >> chlit('-') >>
            +(
                chlit('x') >> lexeme[*(anychar - ' ')][&handle_x_param] |
                chlit('y')[&handle_option_y] |
                chlit('b')[&handle_option_b]
            )
        )
    ];

rule<> cla =
    x_no_param >> x_param;

4) -f (short) is preferred over -f[oo] (long)

rule<> cla =
    lexeme[
        *(
            chlit('-') >>
            (
                chlit('f')[&handle_option_f] |
                (
                    strlit("fo") |
                    strlit("foo")
                )[&handle_option_foo]
            )
        )
    ];

Note that if the final question really means: "How will the framework
detect when I have specified both a short option -f and an
abbreviated long option -foo, and an ambiguity results?", my
response is: Any framework will have to deal with the problem, if so
desired, and certainly before parsing begins. Therefore, any
solution is independent of the parser(s).

Dave


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