Qt-interest Archive, January 2007
How to see QT compiler warnings in VS 7.1 / VS 2003
Message 1 in thread
I'm using QT 4.2.2 with VS 2003 via the default, commercial installation.
When I build a project in Debug mode (it appears to link to the debug QT
libraries correctly), I never see any compiler errors or warnings from QT.
For example, if I have a syntax error in a "connect" macro that fails to
generate any code in the corresponding moc_XXX.cpp file, it fails silently.
If I crank the VS warning level up to 4, I see some warnings from my C++
compiler complaining about QT's libraries (4127, 4511, and 4512
specifically), but I still don't see any warnings from MOC.
Do I need to do anything to enable QT's compiler warnings in Visual Studio?
Michael
Message 2 in thread
Michael Hardt schrieb:
> I'm using QT 4.2.2 with VS 2003 via the default, commercial installation.
>
> When I build a project in Debug mode (it appears to link to the debug QT
> libraries correctly), I never see any compiler errors or warnings from
> QT. For example, if I have a syntax error in a "connect" macro that
> fails to generate any code in the corresponding moc_XXX.cpp file, it
> fails silently.
AFAIK you will never see warnings from a connect at _compile time_! This
is because neither the compiler nor moc has any way to decide at compile
time whether the _string_ "foobar" actually corresponds to an existing
slot - or so I understand. Well, maybe moc would have this possibility
by analyzing the header of the corresponding class, but currently all it
does is generate "glue" code without checking whether the actual methods
(slots) exist.
Only at _runtime_ will you get warnings such as "No such slot...". So
watch the debug output in Visual Studio carefully when clicking on
buttons and the like ;)
That's very annoying, I know. The bottom line is: DON'T MAKE TYPOS IN
YOUR CONNECTS! And while we're at it: DON'T WRITE ARGUMENT NAMES IN YOUR
CONNECTS (ONLY THE ARGUMENT TYPES)!
For example this one will fail at runtime (but not at compile time!):
class Foo : public QObject
{
Q_OBJECT
public slots:
void handleFoo (int a, int b);
signals:
void fooChanged (int a, int b);
}
// this will fail (only at runtime)!
this->connect (this, SIGNAL (fooChanged (int a, int b)),
this, SLOT (handleFoo (int a, int b)));
// this is correct: NO argument names
this->connect (this, SIGNAL (fooChanged (int, int)),
this, SLOT (handleFoo (int, int)));
And yes, how many times did I have to correct such "copy and
paste"-errors (and I'm not the only one, I know that ;) ...
Cheers, Oliver
--
[ signature omitted ]
Message 3 in thread
Thanks for clearing that up. I kind of suspected that QT wasn't issuing
compile-time warnings--although it seems to me that if moc parses a connect
macro but can't generate corresponding code, then moc should be able to
issue an error on the spot.
I never noticed the debug output at runtime. I'll keep my eyes peeled now.
Oh, look--I just tried it, and I got something!
Object::connect: No such signal QCheckBox::stateChanged(int something)
Thanks also for the "no parameter names" tip. I learned that the hard way
on my first day playing with QT, and it's the first place I look now when a
slot fails to fire.
Still learning,
Michael
On 1/24/07, Till Oliver Knoll <oliver.knoll@xxxxxxxxxxx> wrote:
>
> Michael Hardt schrieb:
> > I'm using QT 4.2.2 with VS 2003 via the default, commercial
> installation.
> >
> > When I build a project in Debug mode (it appears to link to the debug QT
> > libraries correctly), I never see any compiler errors or warnings from
> > QT. For example, if I have a syntax error in a "connect" macro that
> > fails to generate any code in the corresponding moc_XXX.cpp file, it
> > fails silently.
>
> AFAIK you will never see warnings from a connect at _compile time_! This
> is because neither the compiler nor moc has any way to decide at compile
> time whether the _string_ "foobar" actually corresponds to an existing
> slot - or so I understand. Well, maybe moc would have this possibility
> by analyzing the header of the corresponding class, but currently all it
> does is generate "glue" code without checking whether the actual methods
> (slots) exist.
>
> Only at _runtime_ will you get warnings such as "No such slot...". So
> watch the debug output in Visual Studio carefully when clicking on
> buttons and the like ;)
>
> That's very annoying, I know. The bottom line is: DON'T MAKE TYPOS IN
> YOUR CONNECTS! And while we're at it: DON'T WRITE ARGUMENT NAMES IN YOUR
> CONNECTS (ONLY THE ARGUMENT TYPES)!
>
> For example this one will fail at runtime (but not at compile time!):
>
> class Foo : public QObject
> {
> Q_OBJECT
>
> public slots:
> void handleFoo (int a, int b);
> signals:
> void fooChanged (int a, int b);
> }
>
> // this will fail (only at runtime)!
> this->connect (this, SIGNAL (fooChanged (int a, int b)),
> this, SLOT (handleFoo (int a, int b)));
>
> // this is correct: NO argument names
> this->connect (this, SIGNAL (fooChanged (int, int)),
> this, SLOT (handleFoo (int, int)));
>
> And yes, how many times did I have to correct such "copy and
> paste"-errors (and I'm not the only one, I know that ;) ...
>
> Cheers, Oliver
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Message 4 in thread
Von: "Michael Hardt" <mhardt@xxxxxxxxxxxxxxx>
> Thanks for clearing that up. I kind of suspected that QT wasn't issuing
> compile-time warnings--although it seems to me that if moc parses a
> connect
> macro but can't generate corresponding code, then moc should be able to
> issue an error on the spot.
>
moc can't parse the connects - at least it can't figure out if the slot really exists. This can only be done on runtime.
IIRC qdbus creates slots dynamically on runtime which would not be possible otherwise.
Christian
--
[ signature omitted ]
Message 5 in thread
Christian Ehrlicher schrieb:
> Von: "Michael Hardt" <mhardt@xxxxxxxxxxxxxxx>
>> ...
>> macro but can't generate corresponding code, then moc should be able to
>> issue an error on the spot.
>>
> moc can't parse the connects - at least it can't figure out if the slot really exists.
That's correct! And this is because in a statement like
Foo *foo;
...
connect (this, SIGNAL (...),
foo, SLOT (...));
you have no way at compile time to find out the _dynamic type_ of the
object 'foo' (that's why it is called "dynamic" after all, because it
can change at runtime ;)
So when you cannot know the type of 'foo' at compile time you also
cannot parse any class file - which one should that be?
Also note that you can connect/disconnect at runtime which also
indicates that one cannot verify the existence of slots at compile time.
Cheers, Oliver
--
[ signature omitted ]
