> 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
