Re: [boost] Re: arguments parsing, wildcard matcher

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-11-19 04:26:21

Hi Gennadiy, 

> Here what I am looking for to be supported by Command Line Argument
> Framework directly or by means of easy extension:
>
> 1. command line argument formats
>   a. -<one letter key> <value>
>   b. -<one letter key><value>
>   c. -<key> <value>
>   d. -<option> - any length
>   e. /<key> <value> - and all other cases like a,b,c but with /
> instead
>   g. --<key> <value>
>   h. -<key substring> <value>

All these can be supported, as well as (i-l) suggested by Petr Ovchenkov.
Two questions:
1. I find it quite OK to have very restricted default syntax 
(--foo=10 and -c100) with other options turned on explicitly. Is it ok for 
you?
2. In (c,d) options, I see possible problem. How one would tell
if "-cfoo" is short option c, with parameter foo, or just long option cfoo, 
without parameter?

>     An example: let say you expecting argument -osagent_port
>     then following argument lists should be valid:
>        -o 15000
>        -osa 15000
>        -osagent_port 15000
>     On the other hand it should perform validity checks. For example
>     if you also expect another argument -osagent_host. then first 2
>     argument list above should generate runtime error and 3d should
>     pass. 
Very reasonable.

> 2. argument types
>    I should be able to explicitle specify expected argument type. For
> example: std::string, int, double, option(bool). The framework should
> perform value validation. For example 1.23 is not valid for int
> argument. 
This is already supported via notion of 'validator. I'm considering a 
possibility of making them even more convenient, so that you could write:
config_db::options_description desc;
desc.add_options() 
            ("magic", parameter<MagicType>("value", &magic), "")
        ;

> The framework should allow to use user-defined classes as
> expected types for command-line argument. In other word. If I provide
> you a class with predefined psecification framework should try to
> generate object of argument class. Some simple extention you can
> provide youself. For example, using following command line you should
> be able to generate std::list<int>
>      -values 2 5 7 8
> and using following command line you should be able to generate
> std::list<std::string>
>      -files_to_test test1.td test2.td test3.td test4.td
> and using following command line user should be able to provide
> argument class A to generate std::list<A>
> struct A{
> std::string key;
> int         value;
> };
>
> -parameters_mapping name1 4 name5 7 name6 8 name9 1123

This all are resonable requests. Would you mind requirement that all such 
types be convertible to and from string?

> 3. argument storage.
>   a. Framework should be able to generate and store arguments
> internally. In this case framework in responsable for memory.

The situation now is that first list of (option_name, parameter) pairs is 
generated and then it's optionally assigned to variables_map, which then cast 
yield any type of object in style of lexical_cast. What you say here sound 
like you'd like conversion in style of any class. Am I right? If so, nothing 
prevents creating class "any_map"...
>   b. Framework should be able to generate and store argument into the
> user-bound location. In this case user in responsable for memory.
At the moment, description of option has boost::function<void, string> 
notify() method. I expect this method to be used for storing value in user 
specified location, and such funtionality is already present.

> 4. arguments can have default values
Sure! Supported.

> 5. arguments can be optional and required. The framework should
> automatically check presence of of all required arguments.
Okay, not supported yet. Will think about it.

> 6. argument value access
>   a. if user passed storage location - he will be able to get value
> from there
>   b. by name and type. If any of them is incorrect - error. The same
> rules aplied here as in 1.h if argument matching algorithm allows
> substrings.
And by name only? With just string returned?
>   c. is_present check - to be able to check presence of optional
> arguments.

> 7. usage line.
>   The framework should be able to generate a using line given a
> difinition of all feilds. To support this you will probably need
> argument description as one of the command line argument
> constructor's argument. Thr framework should be able to configured to
> use different usage line. If command line contain predefined keyword
> (-help or /? for example) framework should print usage message.

I'm a little unsure about this part. The problem is that command line options 
should be documented somewhere, and command line parsing library can't be 
made to generate that documentation. I.e. you'll have to write option 
description yourself. Then, why generate another one by command line parser? 
For fear that docs and code will get out of sync?

> 8. Framework Error
>   If any of the following condition occures during command line
> processing the framework should generate an error
Sure.
> and print a usage
> line:
Always? Unconditionally?
>    a. invalid aargument
>    b. ambiguous argument
>    c. invalid value for the argument
>    d. absence of required argument
>    e. framework meet -help (of any other predefined keyword)
>
> Invalid name or type should generate exception during value access.
>
> Here my view on the problem.

Thank you for your comments!

> P.S. Did you look into Brat Appleton's work? It seems to be close to
> what you are doing.

Yes, but it's not quite what I'd like. The problem is that:
1. There's no low-level interface and some persons might want one.
2. It requires you to store options in variables of few predefined types.
This is a little obtrusive: just for the sake of command line parser you need 
to change the type of variables that control your entire program.

- Volodya