[Development] Qt Playground - Command Line Parser experiment

Oswald Buddenhagen oswald.buddenhagen at nokia.com
Thu Mar 15 13:00:43 CET 2012


On Thu, Mar 15, 2012 at 10:53:59AM +0100, ext David Faure wrote:
> On Monday 12 March 2012 20:06:22 marius.storm-olsen at nokia.com wrote:
> > c) The parser only focuses on the "standard" for a single platform. 
> > (Linux users will not go for Windows style /? options, and Windows users 
> > won't accept --help Linux options, etc)
> 
> Right, that one is true of KDE's KCmdLineArgs (which I want to see disappear 
> due to bad API and not great implementation). It knows -s and --long.
> But surely supporting /s on Windows where -s would work on Linux is trivial.
> 
it's not as simple as that ...
for one, -s and /s have different semantics. it's -ab, but /a/b. the only
universal syntax is always separating by spaces, which is mildly annoying.

of course one can go for a "neutral" syntax like the qt tools use:
- no option "merging" (-a -b != -ab)
- options of any length treated equally
- additional second dash ignored (some qt tools do that)
- on windows, accept a leading slash (no qt tools do that, actually).
  cannot accept that on unix, as no distinction from path names is
  possible. on windows, some os tools actually accept unix paths (the os
  functions all (?) accept them), but then the path must be explicitly
  quoted (note that the argv interface permits no distinction between
  the two (because /foo and "/foo" are parsed the same)).

this does not "feel at home" for unix (where gnu getopt long option
style is considered normal).
windows is a mess anyway, actively promoted by ms (dos had an os
function to change the switch char. it was an epic failure). i'd
actually use that as an argument to simply go for gnu getopt syntax.

but whatever. just saying. ;)



More information about the Development mailing list