[Development] Qt Playground - Command Line Parser experiment

marius.storm-olsen at nokia.com marius.storm-olsen at nokia.com
Thu Mar 15 16:17:41 CET 2012

On 15/03/2012 08:32, ext Hugo Parente Lima wrote:
> On Thursday 15 March 2012 09:23:27 marius.storm-olsen at nokia.com wrote:
>> The applications I mentioned are "bastards" when it comes to
>> commands/actions/options, and I mentioned them on purpose to facilitate
>> discussion. They don't represent valid use-cases, but rather indicate
>> the extremes. It's a balancing act though, to figure out which features
>> to support, and which ones to ignore to capture the 90% without getting
>> too complex.
> Answering according to what I implemented 2 months ago and is on github:
>> For example:
>> * Do short options only accept single letter, or can they have more?
>>       -E for preprocessing in GCC, /E or /EP with MSVC
>>       -reverse for Qt apps
> You must have a clear definition of what is a short option then, if you mean
> options that doesn't require a value, ok, it's supported. sorry if I didn't
> get what you meant.

Sure, you can define /EP as a long option, but then you definitely need 
to support single-dash long options (which you would need to on Windows 
anyways, since no one does //EP :)

>> * Will 'single dash' long options be allowed?
>>       -traditional-cpp in gcc
>>       -style=foo for Qt apps
> Yes, it is.
>> * Will short option clustering be allowed? What if short options support
>> more than one letter?
> Option clustering is allowed.
> If the short option has more than one letter it isn't short.

Fair enough.

>> * What if the clustering of some short options match another single
>> short option, or a long option if single dash long options are allowed?
> IMHO it's a programmer failure to support: -a, -b and -ab
> IIRC in my implementation the class tell the user used all options.

IMO you have 3 possibilities if -ab is passed, were only 2 are acceptable:
1) Mark all premutations as selected (-a, -b, and -ab).
    This is probably not what the end user meant, alas bad.
2) Warn the developer when he runs the application that
    there are options which shadow each other, and show
    which ones they are.
3) Allow for option shadowing, so -ab is unique from passing
        -a -b

>> * Do you allow for turning on/off boolean values with preceeding +/-?
>>       MSVC uses trailing '-' to turn off options, like /GR- to
>>       turn off RTTI
> Isn't implemented, but it easy to do, anyway I don't know other application
> besides cl.exe that users this pattern.

Ex: gvim + foobar.cpp # Jumps to EOF
     gvim +10 foobar.cpp # Jumps to line 10

I'm sure there are others.

>> * Do you use space, '=', ':' or nothing as a option/value separator?
>>       -o<filename>
>>       -output<filename>
>>       -output:<filename>
>>       -output=<filename>
> The current implementation accepts space or "=" as separator, add support for
> other separators should not be a hard task.
>> There's lots of nuances to evaluate. You could say lets just support
>> getopt, but then you're likely falling into the unix-world-only trap.
>> But I guess, "so what"? ;)
> Yes, there are, IMO we just need good defaults and some flexibility without
> complicating the API for ultra-corner cases.

Also, how about support for multiple values for an option, separated by ','?
     gcc -Wl,--defsym,__stack_limit=0x7ffe0000'
Probably an ultra-corner case?

Some other implementations to take a look at perhaps:

Note that due to Windows "corky" command-line handling, the parser 
probably would want to integrate more low-level on Windows to ensure 
that argument parsing is as close as possible on the various platforms.

See http://blogs.msdn.com/b/oldnewthing/archive/2010/09/17/10063629.aspx 
for details.

Yes, the worms are multiplying ;)


More information about the Development mailing list