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
> 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,
> 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
> It seems we'll make no progress with this question. I find your syntax
> 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
> > 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
> Fine, what does it mean? Would anyone like to write such cryptic code? A
> better idea is write
> Now, "unified_context_lines" is the long name, used in program. You can
> 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
> >> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk