Is this a known bug in moc?
I wanted to use the following signal
Code:
void QNetworkAccessManager::sslErrors (QNetworkReply * reply, const QList<QSslError> & errors ) [signal]
so I wrote this
Code:
QObject::connect(nam,
SIGNAL(sslErrors
(QNetworkReply
*, QList<QSslError>
const &)),
this,
SLOT(ssl
(QNetworkReply
*)));
and got an error about non-existen signal... Changing above to
Code:
QObject::connect(nam,
SIGNAL(sslErrors
(QNetworkReply
*,
const QList<QSslError>
&)),
this,
SLOT(ssl
(QNetworkReply
*)));
solved the problem.
Is this a known bug in moc?
Re: Is this a known bug in moc?
Seems like you are describing correct operation. The slot parameter signature of your working option matches the definition of the signal i.e. the QMetaObject::normalizedSignature method returns that string exactly for the slot. The other doesn't.
Re: Is this a known bug in moc?
If at all then not in moc but rather in QMetaObject::normalizedSignature(). But in general this should work, maybe the problem is somewhere else?
If it's known - that I do not know but you can check that yourself using the task-tracker.
Re: Is this a known bug in moc?
Could you clarify, please?
Do you agree this is a bug or not?
Re: Is this a known bug in moc?
Quote:
Originally Posted by
wysota
Yep.
Quote:
Originally Posted by
wysota
But in general this should work, maybe the problem is somewhere else?
It should work but it doesn't work. We have two identical (from C++ pov) signatures and one is treated differently by moc than the other. Isn't this clearly a bug?
What do you mean by maybe the problem is somewhere else?
Quote:
Originally Posted by
wysota
If it's known - that I do not know but you can check that yourself using the task-tracker.
There were a couple of tickets about moc and signatures, all fixed.
I created a ticket for this.
Re: Is this a known bug in moc?
Quote:
Originally Posted by
ChrisW67
Seems like you are describing correct operation. The slot parameter signature of your working option matches the definition of the signal i.e. the
QMetaObject::normalizedSignature method returns that string exactly for the slot. The other doesn't.
But in the end, the meaning of both signatures is equivalent. I guess that is what Piotr wanted to point out. I'd say this is a bug, then.
Re: Is this a known bug in moc?
Quote:
Originally Posted by
piotr.dobrogost
It should work but it doesn't work. We have two identical (from C++ pov) signatures and one is treated differently by moc than the other. Isn't this clearly a bug?
The documentation gives an example almost identical to yours (it uses a pointer and not a reference), so I assume they checked that it works. You might check if changing the reference to a pointer makes it work.
Quote:
What do you mean by maybe the problem is somewhere else?
In some other part of the code or because of some non-printable character. I'm just guessing, it's simply hard to believe the example from the docs doesn't work.
Quote:
There were a couple of tickets about moc and signatures, all fixed.
But moc has nothing to do with this...
Re: Is this a known bug in moc?
Quote:
Originally Posted by
wysota
I'm just guessing, it's simply hard to believe the example from the docs doesn't work.
What I presented in my op is not the example from the docs but my code. I only copied and pasted signal declaration directly from the docs to show it's part of qt and not mine.
Quote:
Originally Posted by
wysota
But moc has nothing to do with this...
In the most narrow sense moc is only a compiler but in a broader sense it's name of whole concept, system (name it as you like) which this compiler is only one part of. When using moc in the second sense QMetaObject::normalizedSignature() is vital part of moc.
On the other hand, if we agree moc is only a compiler than how should we call the whole system of meta information in qt?
