Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-28 01:09:03

Rozental, Gennadiy wrote:

> 1. You store something inside class cmdline

Actually, only arguments, for the benefit of folks which might use 'cmdline'
standalone. Options are not stored there.

> 2. You store strings in options_and_arguments
> 3. You store typed values in variables_map
> In my opinion 2 places are redundant. You should only have one.

OK, I understand your opinion. I'm probably misusing "you don't pay for what
you don't use" principle, but I find that 'options_and_argument' class is
important. Sometimes you really don't need typed storage.

>> > Plus second layer managing composition of parameter originated by
>> > different sources.
>> That's 'variables_map'.
> But variables map is part of first layer, it's store typed arguments. And
> it almost
> does not have any functionality I expect to see on this second layer
> dedicated to combinind parameters from different sources.

It's possible to link several variables_map instances in a chain, which
handles the primary need: different preference of options from different
sources. It's true that different naming of options is not handled, however
I'm still considering if it's better to do that in parsers.

>> >> > b. Force same style for all parameters in command line (I could
>>>> > define /h --my_long_param)
>>>> Do you need it in practice?
>>> Why not. Maybe different modules require parameters in different
>>I feel this to be artifical example, and would not be surprised if no
>>of program_options will ever want it. And if it wants... custom parsers
>>can be used.
> But this is part of functionaly you supply out of the box. And now i need
> ot rewrite it.
> You keep repeating: "use custom parser". I wonder why would I need this
> framework then.

1. I think that less than 1% of users would ever need it. In that case,
there's nothing wrong with asking that 1% to put some effort for their
special needs.

2. BTW, you've said that I can't have "/h --my_long_param" and I've started
to argue that this style is rare and custom parser can help. But really,
that style *is* supported. There no "unix" style and "windows" style, but
rather a set of possible syntaxes. So, (cmdline::unix_style |
cmdline::allow_slash_for_short) enables the syntax you want.

> In my terms above would look like this:
> parameter<std::string>( "output" )
> << place_to( output_file_name )
> << default_value( "/tmp/abc" )
> << description( "output file name" )
> You do not need to know anything in addition about how parser works.
> Moreover it's unifies and easily extendable to adopt different modifers.

It seems we'll make no progress with this question. I find your syntax more
verbose, and it still leaves questions. What if I have "--output foo
--output bar" or when does default value plays: can I write simply
"--output", without any value?

>>With iterators, that would become
>> for(cmdline_iterator i(...), e; i != e; ++i) {
>> if (i->is_option()) {
>>Wait! Again, what's 'value_type'. Some imaginary 'option_or_argument'
>>boost::variant? boost::any? Yep, that would be an interator, but you
>>nothing. It will be only input iterator, and with such a specialized
>>'value_type', that to use that iterator, you need to known that you're
>>dealing with command line --- there's no place for genericity.

> In my design I provide rnadom access iterator to the storage of parsed
> arguments of
> type cla::argument. And I could use whatever generic algorithm I like with
> it.

Let's then postpone this question until your library is reviwed. I found
that 'argument's interface is too lean to make any use of it, but if that's
really so if not question about my library.

> Why does anybody need raw_option_name()?

In short, this supports scenario where you define a group of options as
valid, using "*" symbol

        ("diff_option.*", "", "")

This would allow your program to accept everyting starting with
"diff_option.". In this case, you really don't want to list all options of
'diff' as supported. It seems that multi-pass parsing won't help here.

> Also it's beyond my understanding why we need at_option, at_argument. May
> be it's because I still could not get what meaning you use for these terms
> in this context.
> I parsed argc/argv, stored typed argument. Now I only need ot get the
> value
> out of argument I identifued somehow (by name, or index, or order -
> whatever)

You don't need 'at_option'/'at_argument' because you parse either all
options or all arguments. When you parse them at the same time, your really
have to know that's next on command line.

>>> > 9. Multi-pass parsing support
>> If that's not sufficient (which I doubt), I can think of a more general
>> solution. Basically, 'cmdline' class can allow unregistered options.
>> With
>> a bit of tweaking, it can return unparsed tokens.
> There is a solution. But it's not trivial. And not in a bound ot your
> current design.

We'll see...

>> I don't see here handling of response files or config files... if you
>> were
>> to add it, would you write the same "if" block a couple of times?
> I may have several if spatements:
> if( cla_parser.parse(...) ) ...
> if( config_file.parse(...) ) ...
> ...
> It's not worse than several catch clauses. Try/catch seems redundant when
> used right aroung the function that throw an exception.

But it's worse than *one* catch clause --- which can be the 'catch' clause
already present in your 'main' function (at least in my 'main' functions).

>>> > Moreover in many interfaces library assumes existence on long
> name,
>>> > short
>>> > name, which may not be the case even with name based parameter
>>> > identification.
>>> I don't understand what you mean here.
>> > I may not have long name, but only short one, like with old getopt
>> had.
>> It's not a problem. You'd still use the long name for identification
>> purposes, but disable long names in command line.
> I don't get it. What long name would I use if it only have short name.

Whatever long name you like. You've been talking about maintenance
programmer previously. Now imagine he looks at


Fine, what does it mean? Would anyone like to write such criptic code? A
better idea is write


Now, "unified_context_lines" is the long name, used in program. You can have
only "-u" in command line, no problem.

Note that "-u" probably can be used as key even now. But I think it's very
bad idea.

>> > I may not have short name but only long one, like the style I am
>> > personally prefer.
>> What's problem with this case? It's supported out-of-box.
> What would you return when user call short name method?

You mean option_description::short_name()? Empty string will be returned.
What's wrong with that?

>>> > 15. External parsers support.
>> > I do not want to store parsed values inside the parser at all. Instead
>> I
>> > want to register for every parameter callback function.
>> That's another example I don't see any use for. What will those callback
>> functions do. Can you given some more details why it might be needed?
> Let say I have method set_trace_level that manage tracing level for you
> application.
> What I need is in my terms look like this:
> parameter<int>( "trace_level" )
> << default_value( 0 )
> << handler( set_trace_level )
> << description( "specifies the trace level for the application" )
> Now when argc/argv parsed argument value is not stored into list of
> parsed argument. Instead
> handler function call and parsed value passed.

The 'notify' function has this functionality. However, it can be called only
*after* parsing. That's an explicit decision -- if you're to support both
string-only interface (syntantic) and typed interface (semantic), you have
to clearly separate the two, and 'notify' belongs to semantic interface.

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at