From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-05-29 05:37:39
> 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.
Then just use default std::string type for parameter types - you got your
string to string parser.
IMO options_and_arguments is redundant.
> 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.
I do not say it should be done in parsers. But this is only one conflict
resolution strategy. There may be many more. And what important different
parameters may have different strategy: for trace level we prefer CL value
to the environment. For debug/release mode switch we may want to use "and"
or "or" logic.
> > 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
modifiers.
>
> 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
Parameter above is not declared multipliable.
> when does default value plays: can I write simply
> "--output", without any value?
No. This is parameter. It's required to have a value. Seems obvious to me.
If not parser will generate the error.
> >> 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 statements:
> > 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).
It's unfair comparison. I could also write one if:
if( ! cla_parser.parse(...) || ! config_file.parse(...) ) ...
But I most probably would not want to do so, cause I want to show different
messages depends on what failed.
To be more close to the topic, could you show any practical usage for the
exception classes you defined in error.hpp.
> > 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
>
> vm["-u"].as<int>()
>
> Fine, what does it mean? Would anyone like to write such cryptic code? A
> better idea is write
>
> vm["unified_context_lines"].as<int>()
>
> Now, "unified_context_lines" is the long name, used in program. You can
have
> only "-u" in command line, no problem.
But parameters definition does not contain "unified_context_lines" name at
all. So it's questionable what is more confusing: see unreadable name that
you can find among defined parameters or use readable name that is not
mentioned there. I believe that if programmer was that "smart" to use short
names for command line arguments declaration the same names should be used
everywhere.
> >> > 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?
This methods is redundant in this case. IMO there should not be redundant
methods in any way library is used.
Gennadiy.