Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-15 09:30:36

Patrick Guio wrote:

> > Okay. Going back to parsing '-I' options, I think that implementing
> > 'ParseOptions' is something that doesn't looks good to me. It is possible
> > to allow more flexible solution, where each types decides for itself how
> > it deals with each arguments. For example, validator for vector just
> > appends new element each time it's called. Isn't it more general?
> That could easily be done actually. Separating with a predefined separator
> sign (':' as for PATH variable)

Do you mean that Convert method would be called with all the arguments
separated with ":"? That would not be, strictly speaking, general solution.

> > > > 2) parsing arbitrary class and thowing if the value given for it is
> > > > incorrect
> > >
> > > I guess anyone could extend its own parser by inheriting this one and
> > > write its own Convert(string, value) routine where value is a class
> > > object. The Parser::ParseOption functions are template member function
> > > that parse the command line arguments for a special option and feeds
> > > the rest of the string (or the next arg) to the Convert function
> >
> > Well, actually Convert looks a bit like lexical_cast, so you might use
> > it. Secondly, I don't think that inheritance is good in this case. After
> > all, all you do is tell how to handle some time.
> I haven't looked at lexical_cast but it sounds good. How can you easily
> provide extension to Convert or lexical_cast ?

Well, very long ago we've discussed this with lexical_cast author, Kevlin
Henney. IIRC, the most easy method would be to have global function ( or
function object)

        template<class T>
        interpret(const string& s, T&);

Users could then overload it for their types. However, this change is not
applied yet :-(

> > Why can't you have special processing from help/version/template-creation
> > and then a single method that will parse the remaining options?
> That could be a possibility but so long I have used individual fields in
> classes with long and descriptive names so that each field is parsed
> separately. A single method to parse the remaining options is of interest
> when the values are to be parsed in a unique vector (a class any would
> be nice but it does not contain so long input method) but then you miss
> clarity of the code. Do you see what I mean or am I wrong?

I'm not sure. Suppose you say to a library something:
"option 'file', if found, should be stored to variable 's'". Why do we miss
any clarity?

> > 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>
> So long the option and aliases are registered by the Parser so the option
> name and aliases can be whatever you want. The two rules I use to
> parse are
> * either the argument is in the same element but separated by =
> <option>=<value>
> * or the argument is the next element list
> <option> <value>
> But I guess it could be possible to tune these settings

Okay. I'll reshuffle my priorities a little and will try to find out which
ambiguities appear when diverse styles are wanted and how they can be
handled. I'll post my findings later.

- Volodya

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