[Qt-interest] Can you spot my mistake.

[Andrew Hodgkinson]

On 24/08/2009 15:53, Thomas Dähling wrote:

> Personally I am even curious why it is not doing a simple value copy
> of argc anyway? I do not see a specific reason for passing a reference
> there.

Since QApplication can modify the argument list, it can't do a simple 
copy, given that, as presently designed, it wants to make sure that the 
calling application gets a sanitised list of arguments afterwards. 
Otherwise, if it deletes arguments (which it does), the value of argc 
would no longer match the corresponding argv and code examining the 
arguments after the QApplication object instantiation would end up 
running off the end of the now-shorter list.

An arguably cleaner alternative might have been to pass read-only 
arguments to QApplication. If the caller wanted to examine the arguments, 
they'd always get all of them - both Qt-understood and self-defined 
arguments all mixed together. Big deal; ignore options you don't 
understand. But QApplication could also provide an interface to getting 
at any of the arguments it didn't consume, making life easier for the 
application developer, perhaps using an approach similar to some of the 
C++ getopt()-on-steroids libraries out there.

Meanwhile, on 24/08/2009 15:33, John McClurkin wrote:

> Namespace collisions have been a problem for quite awhile. The
> QApplication class reference does provide a list of argument names of
> which it claims ownership.

As far as Nokia/Qt go, the documentation saying "there's a list of 
arguments" is hopeless. If the next version of Qt adds a new argument, 
what happens if there's a collision with my existing application? I'm 
stuck having to redefine my CLI interface and explain to users that 
option "foo" is now very different and they should use "bar" instead, or 
I'm stuck permanently on an old Qt library version.

IMHO a reasonable approach would be to acknowledge the historical lack of 
namespace provision but state that any future additional Qt-specific 
command line arguments will use names prefixed with, say, "qt". 
Application authors can use anything *except* "qt*" or the list of 
existing arguments and their code will work fine if they upgrade to a 
newer Qt library. Sadly, I see no such comment in the documentation, 
though I would be delighted to find out that it's present and I've merely 
overlooked it.

-- 
TTFN, Andrew Hodgkinson
Find some electronic music at:     Photos, wallpaper, software and more:
http://pond.org.uk/music.html                        http://pond.org.uk/