[Development] Qt Playground - Command Line Parser experiment

Hugo Parente Lima hugo.lima at openbossa.org
Thu Mar 15 19:00:19 CET 2012


On Thursday 15 March 2012 12:17:41 marius.storm-olsen at nokia.com wrote:
> 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.

IMO this would be acceptable only if this check could be done only on debug 
builds.

> 3) Allow for option shadowing, so -ab is unique from passing
>         -a -b
>     or
>         -ba

And what if the scumbag developer create the options: -a, -b, -ab and -ba? =]
 
> >> * 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.
> 
> (g)vim?
> Ex: gvim + foobar.cpp # Jumps to EOF
>      gvim +10 foobar.cpp # Jumps to line 10

This "+10" would be represented as "positional arguments" like the 
"foobar.cpp".
 
> 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?

I believe this is, as you said, a ultra corner case. but it's not too hard to 
implement, I just don't know if is worth to implement this.
 
> Some other implementations to take a look at perhaps:
>      http://llvm.org/docs/CommandLine.html
>      http://www.doughellmann.com/PyMOTW/argparse/

Yes, I was inspired by the Python argparse API, although I didn't check the 
llvm one yet, thanks for the suggestion.

> 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.
> and
>    http://msdn.microsoft.com/en-us/library/zay8tzh6.aspx
>    http://msdn.microsoft.com/en-us/library/ms683156.aspx
>    http://msdn.microsoft.com/en-us/library/ms647232.aspx
> 
> Yes, the worms are multiplying ;)

Yes, they are, but I think most of them are mortals and can be killed =]

-- 
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120315/350ac21c/attachment.sig>


More information about the Development mailing list