Re: [boost] Command line option handling - Interest?

From: Sven M. Hallberg (pesco_at_[hidden])
Date: 2001-05-10 16:22:58

On Thu, May 10, 2001 at 09:51:24AM -0700, Gary Powell wrote:
> 
> > The programmer needs to specify both denominators denominators seperately.
> > Autogenerating the short form would be too much guesswork in my eyes.
> Ok, I've done both in the past. Mostly I've let the parser pick the flag
> that fits best. i.e.
> -ThisOptionIsReallyLong
> -ThisOptionIsShorter
> -T
> -TMedium
> 
> foo -T  //Ok
> foo -TM  // Ok
> foo -This  // Ambiguous flag
> foo -ThisOptionIsR  //Ok
> 
> As in if there is an exact fit, that's the flag selected.
> If there is a unique match that's ok too. As opposed to making the
> programmer add a "short" form.
> This way if you want a short flag, you just add it twice.
> 
> -ThisOptionIsReallyLong, "Long form Of Option", Callback
> -TOIRL, "Short version of flag", Callback
> 
> It simplifies the programmers interface, at the cost of greater processing
> to determine the unique flag.

Oh I see. I was assuming the POSIX way: double dashes for longopts, single
dashes for shortopts. I'd personally prefer that approach, for the following
reasons (in order of appearance):

1.
The possibility for combining several shortopts in one argument. Think
"diff -Naur".

2.
It's pretty common to have short forms for all the most important options.
Specifying them all seperately is tedious and bloats the help output.
In a clean program, you will have to make them all explicit because
otherwise they couldn't be used in scripts and thelike (anywhere their usage
is hardcoded) or adding a new opt with the same first letter will instantly
ambiguate the short form and break the script.

3.
Actually the programmers interface doesn't suffer all too much. You basically
have three forms of the register function:

 reg(handler, descr, short_chr, long_name);  // full-blown
 // for convenience
 reg(handler, descr, short_chr);
 reg(handler, descr, long_name);

4.
POSIX-compliance is important to (virtually) all UNIX applications while
Windows-apps at least wouldn't suffer from it. ;)

> You should at least include "config.hpp" and make the include defines
> "BOOST_...."

Will do.

> And it "depends" as in if you would like comments on your current code, or
> like me, would prefer to keep your messes away from public view until you
> are more ready. Thick skin is always an asset.  On the otherhand wasting a
> lot of time "cleaning" only to get a recommendation that removes the need
> seems like a lot of work for nothing.

*g*. I agree, better finish the obvious cleanup first, making sure the thing
is good, thereby reducing the chances of getting "a recommendation that
removes the need". :)

> Sometimes its best just to post interface questions and not worry about the
> implementation until you have that nailed down. (Witness all the math
> constant discussions and revisions.)

Alright, so here's the outer interface's synopsis:

class option_processor {
public:
    // argname: Symbolic name for the argument to be used in the help.
    //          "" means try to guess from desc, use "ARG" if ambiguous
    template<class H> reg(H hdlr, string desc, char chr, string name,
                          string argname = "");
    // convenience
    template<class H> reg(H hdlr, string desc, char chr);
    template<class H> reg(H hdlr, string desc, string name);
    
    string info() const; // return the help listing

    void operator()(int* argc, char** argv[]);
};

I have to rework the handler objects again, considering using a boost
callback type, so I won't go into detail. Right now I have convenience
functions for their creation:

// creates a no-argument handler
handler(void (*func)());
template<class F> noarg_handler(F func); // special case for function objects
// creates a mandatory-arg handler
template<class F> handler(F func);
// creates a optional-arg handler supplying a default to its function if
// no argument is given.
template<class F> handler(F func, F::argument_type def);

But I'm suspecting this is a less-than-optimal solution. Especially the
special case for non-arg function objects. Ugh.

I think the problem that lead me to all this was that I wanted to relieve the
programmer from processing a string argument, so I needed a functor that does
the conversion from string to the function's argument type. Any suggestions
welcome.

> i.e. Have you looked at boost/regex? and boost/smart_ptr.hpp?

I have successfully put smart_ptr to use already. The class I had used
previously was almost identical to it. :)
Currently I am just in the process of switching to boost/regex, fighting some
bug I must have planted somewhere. I need sleep.

Good night,
Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]