| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 2 | |
Would it be that hard for the SIGNAL/SLOT functions that are used in the connect and disconnect functionality to ignore the parameter names! Just spent another ½ hour of my life wondering why Im getting the no such signal warning, because I was connecting SIGNAL( foo( int bar ) ) as opposed to SIGNAL( foo( int ) ) Its already doing a bunch of parsing... would it be that hard? Rant off... Back to your regularly scheduled programming.... Scott
I agree with Scott! The ³warnings² are too vague. On 10-05-2006 7:54 PM, "Scott Aron Bloom" wrote: > Would it be that hard for the SIGNAL/SLOT functions that are used in the > connect and disconnect functionality to ignore the parameter names! > > Just spent another ½ hour of my life wondering why Im getting the no such > signal warning, because I was connecting SIGNAL( foo( int bar ) ) as opposed > to SIGNAL( foo( int ) ) > > Its already doing a bunch of parsing? would it be that hard? > > Rant off? Back to your regularly scheduled programming?. > > Scott >
I don’t mind the simple warnings… But frankly, it should be able to ignore the parameter names and still make the connection…. Scott ________________________________ From: Keith Esau [mailto:keith.esau@xxxxxxx] Sent: Thursday, October 05, 2006 9:21 PM To: Qt Interest Subject: Re: Rant... just a rant... ignore if you want :( I agree with Scott! The “warnings” are too vague. On 10-05-2006 7:54 PM, "Scott Aron Bloom" wrote: Would it be that hard for the SIGNAL/SLOT functions that are used in the connect and disconnect functionality to ignore the parameter names! Just spent another ∏ hour of my life wondering why Im getting the no such signal warning, because I was connecting SIGNAL( foo( int bar ) ) as opposed to SIGNAL( foo( int ) ) Its already doing a bunch of parsing… would it be that hard? Rant off… Back to your regularly scheduled programming…. Scott
And what about
SIGNAL( foo(char const *) )
that cannot connect to
SLOT( foo(const char *) )
A bit more tricky than a simple parsing issue, but it is annoying.
Didier
Scott Aron Bloom wrote:
> Would it be that hard for the SIGNAL/SLOT functions that are used in the
> connect and disconnect functionality to ignore the parameter names!
>
>
>
> Just spent another ½ hour of my life wondering why Im getting the no
> such signal warning, because I was connecting SIGNAL( foo( int bar ) )
> as opposed to SIGNAL( foo( int ) )
>
>
>
> Its already doing a bunch of parsing… would it be that hard?
>
> Rant off… Back to your regularly scheduled programming….
>
>
>
> Scott
>
--
[ signature omitted ]
Hmm... that doesn't work? Never tried with const char *s, is it a const issue? Or is it the fact that the macros swap/drop the const sometimes? Or is it that it connects, but doesn't work due to the lifespan of the char * at run time? Scott > -----Original Message----- > From: Didier Trosset [mailto:didier.trosset@xxxxxxxxxxx] > Sent: Thursday, October 05, 2006 11:41 PM > To: qt-interest@xxxxxxxxxxxxx > Subject: Re: Rant... just a rant... ignore if you want :( > > > And what about > SIGNAL( foo(char const *) ) > that cannot connect to > SLOT( foo(const char *) ) > > A bit more tricky than a simple parsing issue, but it is annoying. > > Didier > > Scott Aron Bloom wrote: > > Would it be that hard for the SIGNAL/SLOT functions that are used in the > > connect and disconnect functionality to ignore the parameter names! > > > > > > > > Just spent another ½ hour of my life wondering why Im getting the no > > such signal warning, because I was connecting SIGNAL( foo( int bar ) ) > > as opposed to SIGNAL( foo( int ) ) > > > > > > > > Its already doing a bunch of parsing... would it be that hard? > > > > Rant off... Back to your regularly scheduled programming.... > > > > > > > > Scott > > > > -- > Didier Trosset-Moreau > Acqiris <www.acqiris.com> > Geneva, Switzerland > > -- > 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/ -- [ signature omitted ]
Scott Aron Bloom wrote: > Hmm... that doesn't work? Never tried with const char *s, is it a > const issue? Or is it the fact that the macros swap/drop the const > sometimes? Or is it that it connects, but doesn't work due to the > lifespan of the char * at run time? No, simply the fact that the connections are done with the names of the parameters types, and parameter names. Thus "char const *" is different from "const char *", just like your "int bar" is different from "int". Didier A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? > > Scott > >> -----Original Message----- From: Didier Trosset >> [mailto:didier.trosset@xxxxxxxxxxx] Sent: Thursday, October 05, >> 2006 11:41 PM To: qt-interest@xxxxxxxxxxxxx Subject: Re: Rant... >> just a rant... ignore if you want :( >> >> >> And what about SIGNAL( foo(char const *) ) that cannot connect to >> SLOT( foo(const char *) ) >> >> A bit more tricky than a simple parsing issue, but it is annoying. >> >> Didier >> >> Scott Aron Bloom wrote: >>> Would it be that hard for the SIGNAL/SLOT functions that are used >>> in the connect and disconnect functionality to ignore the >>> parameter names! >>> >>> >>> >>> Just spent another ½ hour of my life wondering why Im getting >>> the no such signal warning, because I was connecting SIGNAL( foo( >>> int bar ) ) as opposed to SIGNAL( foo( int ) ) >>> >>> >>> >>> Its already doing a bunch of parsing... would it be that hard? >>> >>> Rant off... Back to your regularly scheduled programming.... >>> >>> >>> >>> Scott >>> >> -- Didier Trosset-Moreau Acqiris <www.acqiris.com> Geneva, >> Switzerland >> >> -- 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/ > -- [ signature omitted ]
On Friday 06 October 2006 08:53, Didier Trosset wrote: > Scott Aron Bloom wrote: > > Hmm... that doesn't work? Never tried with const char *s, is it a > > const issue? Or is it the fact that the macros swap/drop the const > > sometimes? Or is it that it connects, but doesn't work due to the > > lifespan of the char * at run time? > > No, simply the fact that the connections are done with the names of the > parameters types, and parameter names. Thus "char const *" is different > from "const char *", just like your "int bar" is different from "int". Actually these are two completely different types! Qt SHOULD NOT connect signals/slots with these differences. const char * -> is a variable pointer to a constant array of characters. I.e. you can change the pointer but not the space it points to. char const * -> is a constant pointer to a variable array of character. I.e. you can change the memory it points to but not the pointer itself. const char const * -> is a constant pointer to a constant array of characters. I.e. you can't change any of them. Konrad
Attachment:
Attachment:
pgpWj0G06NjvZ.pgp
Description: PGP signature
Message 8 in thread
Konrad Rosenbaum wrote:
> On Friday 06 October 2006 08:53, Didier Trosset wrote:
>> Scott Aron Bloom wrote:
>>> Hmm... that doesn't work? Never tried with const char *s, is it a
>>> const issue? Or is it the fact that the macros swap/drop the const
>>> sometimes? Or is it that it connects, but doesn't work due to the
>>> lifespan of the char * at run time?
>> No, simply the fact that the connections are done with the names of the
>> parameters types, and parameter names. Thus "char const *" is different
>> from "const char *", just like your "int bar" is different from "int".
>
> Actually these are two completely different types! Qt SHOULD NOT connect
> signals/slots with these differences.
>
> const char * -> is a variable pointer to a constant array of characters.
> I.e. you can change the pointer but not the space it points to.
>
> char const * -> is a constant pointer to a variable array of character. I.e.
> you can change the memory it points to but not the pointer itself.
I am sorry you are completely wrong here.
'const char *' and 'char const *' _are exactly the same types_.
>
> const char const * -> is a constant pointer to a constant array of
> characters. I.e. you can't change any of them.
Wrong too. If you want a constant pointer you have to write:
char * const
As a hint that _always_ works: "const applies to what is on its left."
And it it is first, move it one token to the right.
Didier
>
>
>
> Konrad
--
[ signature omitted ]
Message 9 in thread
"Konrad Rosenbaum" <konrad@xxxxxxxxx> wrote in message
news:200610061022.08540@xxxxxxxxxxxxxxxxxxxxxxxxxx
>Actually these are two completely different types! Qt SHOULD NOT connect
>signals/slots with these differences.
>const char * -> is a variable pointer to a constant array of characters.
>I.e. you can change the pointer but not the space it points to.
>char const * -> is a constant pointer to a variable array of character.
I.e.
>you can change the memory it points to but not the pointer itself.
>const char const * -> is a constant pointer to a constant array of
>characters. I.e. you can't change any of them.
No. They're both non const pointers to const char.
FWIW I think this just adds needless complexity but I imagine
that it's like that to support C or something.
I'm not sure how the trolls could deal with this better since
there are several combinations.
--
[ signature omitted ]
Message 10 in thread
Nobody's perfect....
who didn't loose time with this "newbie" coding error?
if you read slots doc and particulary connect documentation, this is clear
"/Note that the signal and slots parameters must not contain any
variable names,
only the type. E.g. the following would not work and return false/"
Maybe here is the solution, generate a qdebug message when connect
return false.
Regards,
Veronique.
Scott Aron Bloom a écrit :
> Would it be that hard for the SIGNAL/SLOT functions that are used in
> the connect and disconnect functionality to ignore the parameter names!
>
>
>
> Just spent another ½ hour of my life wondering why Im getting the no
> such signal warning, because I was connecting SIGNAL( foo( int bar ) )
> as opposed to SIGNAL( foo( int ) )
>
>
>
> Its already doing a bunch of parsing... would it be that hard?
>
> Rant off... Back to your regularly scheduled programming....
>
>
>
> Scott
>
Message 11 in thread
veronique.lefrere@xxxxxx wrote:
> Nobody's perfect....
> who didn't loose time with this "newbie" coding error?
> if you read slots doc and particulary connect documentation,
> this is clear
> "Note that the signal and slots parameters must not contain
> any variable names,
> only the type. E.g. the following would not work and return false"
> Maybe here is the solution, generate a qdebug message when
> connect return false.
I regularily assert on the return value of connect, i.e. something like
void Connect(const QObject * sender, const char * signal,
const QObject * receiver, const char * slot)
{
if (!receiver->connect(sender,
(QString("2") + signal).toAscii(),
(QString("1") + slot).toAscii())) {
const QString sname = sender->metaObject()->className() + QString("::") + signal;
const QString rname = receiver->metaObject()->className() + QString("::") + slot;
LOG("Can't connect " + sname + " to " + rname);
ASSERT(false);
}
}
and use it like
Connect(foo, "clicked()", this, "on_click()");
Might be a bit too close to the guts of Qt and a bit slower
but it works rather well and I also don't have these shouts
(SLOT()! SIGNAL()!) in my main source.
Andre'
--
[ signature omitted ]
Message 12 in thread
Excuse me... but Im not a noob....
I know the correct way, but if I design a functional interface that's turns into a slot, or just creating the slot itself, I will quite often COPY the interface from the header, and wrap it in the SIGNAL/SLOT calls.
That's how the parameter names get in their by accident.
Scott
________________________________
From: veronique.lefrere@xxxxxx [mailto:veronique.lefrere@xxxxxx]
Sent: Friday, October 06, 2006 12:17 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: Rant... just a rant... ignore if you want :(
Nobody's perfect....
who didn't loose time with this "newbie" coding error?
if you read slots doc and particulary connect documentation, this is clear
"Note that the signal and slots parameters must not contain any variable names,
only the type. E.g. the following would not work and return false"
Maybe here is the solution, generate a qdebug message when connect return false.
Regards,
Veronique.
Scott Aron Bloom a écrit :
Would it be that hard for the SIGNAL/SLOT functions that are used in the connect and disconnect functionality to ignore the parameter names!
Just spent another ½ hour of my life wondering why Im getting the no such signal warning, because I was connecting SIGNAL( foo( int bar ) ) as opposed to SIGNAL( foo( int ) )
Its already doing a bunch of parsing... would it be that hard?
Rant off... Back to your regularly scheduled programming....
Scott
Message 13 in thread
For me, the main problem is signal/slot errors that don't get picked up at compile time.
I've been bitten by this by not testing properly: the error shows up when a user complains...
Sam Dutton
SAM DUTTON
SENIOR SITE DEVELOPER
200 GRAY'S INN ROAD
LONDON
WC1X 8XZ
UNITED KINGDOM
T +44 (0)20 7430 4496
F
E SAM.DUTTON@xxxxxxxxx
WWW.ITN.CO.UK
________________________________
From: Scott Aron Bloom [mailto:scott@xxxxxxxxxxxx]
Sent: Friday 06 October 2006 15:35
To: veronique.lefrere@xxxxxx; qt-interest@xxxxxxxxxxxxx
Subject: RE: Rant... just a rant... ignore if you want :(
Excuse me... but Im not a noob....
I know the correct way, but if I design a functional interface that's turns into a slot, or just creating the slot itself, I will quite often COPY the interface from the header, and wrap it in the SIGNAL/SLOT calls.
That's how the parameter names get in their by accident.
Scott
________________________________
From: veronique.lefrere@xxxxxx [mailto:veronique.lefrere@xxxxxx]
Sent: Friday, October 06, 2006 12:17 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: Rant... just a rant... ignore if you want :(
Nobody's perfect....
who didn't loose time with this "newbie" coding error?
if you read slots doc and particulary connect documentation, this is clear
"Note that the signal and slots parameters must not contain any variable names,
only the type. E.g. the following would not work and return false"
Maybe here is the solution, generate a qdebug message when connect return false.
Regards,
Veronique.
Scott Aron Bloom a écrit :
Would it be that hard for the SIGNAL/SLOT functions that are used in the connect and disconnect functionality to ignore the parameter names!
Just spent another ½ hour of my life wondering why Im getting the no such signal warning, because I was connecting SIGNAL( foo( int bar ) ) as opposed to SIGNAL( foo( int ) )
Its already doing a bunch of parsing... would it be that hard?
Rant off... Back to your regularly scheduled programming....
Scott
Please Note:
Any views or opinions are solely those of the author and do not necessarily represent
those of Independent Television News Limited unless specifically stated.
This email and any files attached are confidential and intended solely for the use of the individual
or entity to which they are addressed.
If you have received this email in error, please notify postmaster@xxxxxxxxx
Please note that to ensure regulatory compliance and for the protection of our clients and business,
we may monitor and read messages sent to and from our systems.
Thank You.
Message 14 in thread
I think that is just a plain old ramifaction of signals/slots in QT, and yes, I have been bit by it more then once.
That's why for all my projects, I install a qtmessage handler, that blows assertions on the can not connect warning...
This way they are VERY hard to forget :-)
Scott
________________________________
From: Dutton, Sam [mailto:Sam.Dutton@xxxxxxxxx]
Sent: Friday, October 06, 2006 9:24 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: RE: Rant... just a rant... ignore if you want :(
For me, the main problem is signal/slot errors that don't get picked up at compile time.
I've been bitten by this by not testing properly: the error shows up when a user complains...
Sam Dutton
SAM DUTTON
SENIOR SITE DEVELOPER
200 GRAY'S INN ROAD
LONDON
WC1X 8XZ
UNITED KINGDOM
T +44 (0)20 7430 4496
F
E SAM.DUTTON@xxxxxxxxx
WWW.ITN.CO.UK
________________________________
From: Scott Aron Bloom [mailto:scott@xxxxxxxxxxxx]
Sent: Friday 06 October 2006 15:35
To: veronique.lefrere@xxxxxx; qt-interest@xxxxxxxxxxxxx
Subject: RE: Rant... just a rant... ignore if you want :(
Excuse me... but Im not a noob....
I know the correct way, but if I design a functional interface that's turns into a slot, or just creating the slot itself, I will quite often COPY the interface from the header, and wrap it in the SIGNAL/SLOT calls.
That's how the parameter names get in their by accident.
Scott
________________________________
From: veronique.lefrere@xxxxxx [mailto:veronique.lefrere@xxxxxx]
Sent: Friday, October 06, 2006 12:17 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: Rant... just a rant... ignore if you want :(
Nobody's perfect....
who didn't loose time with this "newbie" coding error?
if you read slots doc and particulary connect documentation, this is clear
"Note that the signal and slots parameters must not contain any variable names,
only the type. E.g. the following would not work and return false"
Maybe here is the solution, generate a qdebug message when connect return false.
Regards,
Veronique.
Scott Aron Bloom a écrit :
Would it be that hard for the SIGNAL/SLOT functions that are used in the connect and disconnect functionality to ignore the parameter names!
Just spent another ½ hour of my life wondering why Im getting the no such signal warning, because I was connecting SIGNAL( foo( int bar ) ) as opposed to SIGNAL( foo( int ) )
Its already doing a bunch of parsing... would it be that hard?
Rant off... Back to your regularly scheduled programming....
Scott
Please Note:
Any views or opinions are solely those of the author and do not necessarily represent
those of Independent Television News Limited unless specifically stated.
This email and any files attached are confidential and intended solely for the use of the individual
or entity to which they are addressed.
If you have received this email in error, please notify postmaster@xxxxxxxxx
Please note that to ensure regulatory compliance and for the protection of our clients and business,
we may monitor and read messages sent to and from our systems.
Thank You.
Message 15 in thread
Hi all,
On Windows, I like to link my debug builds with /SUBSYSTEM:CONSOLE and
release builds with /SUBSYSTEM:WINDOWS (in MSVC). This way, I always see the
debug info like the connect errors in a fairly obvious console window. I
almost never look at the Visual Studio debug console without specific reason
to (low signal:noise ratio), so I miss this output otherwise.
This is a fairly serious coding mistake. It *looks* right, it compiles, and
runs without raising a serious error - trifecta. connect() should either be
more forgiving of or more vocal about parameter names.
There are some great ideas being bounced around here. I think they deserve
some consideration as "best practices".
My $0.02,
Glen.
On 10/6/06, Scott Aron Bloom <scott@xxxxxxxxxxxx> wrote:
>
> I think that is just a plain old ramifaction of signals/slots in QT, and
> yes, I have been bit by it more then once.
>
>
>
> That's why for all my projects, I install a qtmessage handler, that blows
> assertions on the can not connect warningâ
>
>
> This way they are VERY hard to forget J
>
> Scott
>
>
> ------------------------------
>
> *From:* Dutton, Sam [mailto:Sam.Dutton@xxxxxxxxx]
> *Sent:* Friday, October 06, 2006 9:24 AM
> *To:* qt-interest@xxxxxxxxxxxxx
> *Subject:* RE: Rant... just a rant... ignore if you want :(
>
>
>
> For me, the main problem is signal/slot errors that don't get picked up at
> compile time.
>
>
>
> I've been bitten by this by not testing properly: the error shows up when
> a user complains...
>
>
>
> Sam Dutton
>
>
>
>
>
>
>
>
>
> **
>
> *SAM DUTTON**
> SENIOR SITE DEVELOPER
> *
> 200 GRAY'S INN ROAD
> LONDON
> WC1X 8XZ
> UNITED KINGDOM
> T +44 (0)20 7430 4496
> F
> E SAM.DUTTON@xxxxxxxxx
> WWW.ITN.CO.UK
>
>
> ------------------------------
>
>
>
> *From:* Scott Aron Bloom [mailto:scott@xxxxxxxxxxxx]
> *Sent:* Friday 06 October 2006 15:35
> *To:* veronique.lefrere@xxxxxx; qt-interest@xxxxxxxxxxxxx
> *Subject:* RE: Rant... just a rant... ignore if you want :(
>
> Excuse meâ but Im not a noobâ.
>
> I know the correct way, but if I design a functional interface that's
> turns into a slot, or just creating the slot itself, I will quite often COPY
> the interface from the header, and wrap it in the SIGNAL/SLOT calls.
>
>
>
> That's how the parameter names get in their by accident.
>
>
>
> Scott
>
>
> ------------------------------
>
> *From:* veronique.lefrere@xxxxxx [mailto:veronique.lefrere@xxxxxx]
> *Sent:* Friday, October 06, 2006 12:17 AM
> *To:* qt-interest@xxxxxxxxxxxxx
> *Subject:* Re: Rant... just a rant... ignore if you want :(
>
>
>
> Nobody's perfect....
> who didn't loose time with this "newbie" coding error?
> if you read slots doc and particulary connect documentation, this is clear
> "*Note that the signal and slots parameters must not contain any variable
> names,
> only the type. E.g. the following would not work and return false*"
> Maybe here is the solution, generate a qdebug message when connect return
> false.
>
>
> Regards,
> Veronique.
>
>
>
>
>
> Scott Aron Bloom a ïcrit :
>
> Would it be that hard for the SIGNAL/SLOT functions that are used in the
> connect and disconnect functionality to ignore the parameter names!
>
>
>
> Just spent another ï hour of my life wondering why Im getting the no such
> signal warning, because I was connecting SIGNAL( foo( int bar ) ) as
> opposed to SIGNAL( foo( int ) )
>
>
>
> Its already doing a bunch of parsingâ would it be that hard?
>
> Rant offâ Back to your regularly scheduled programmingâ.
>
>
>
> Scott
>
>
>
> Please Note:
>
>
>
>
>
> Any views or opinions are solely those of the author and do not necessarily represent
>
> those of Independent Television News Limited unless specifically stated.
>
> This email and any files attached are confidential and intended solely for the use of the individual
>
> or entity to which they are addressed.
>
> If you have received this email in error, please notify postmaster@xxxxxxxxx
>
>
>
> Please note that to ensure regulatory compliance and for the protection of our clients and business,
>
> we may monitor and read messages sent to and from our systems.
>
>
>
> Thank You.
>
>
>
>
>