2017-07-18 2 views
1

Dans le QT 4.8 documentation il indique que:Où se trouve la documentation indiquant que vous ne pouvez pas supprimer un paramètre d'une connexion de logement de signal QT si le paramètre ne provient pas de la fin?

Le mécanisme des signaux et des fentes est de type coffre-fort: la signature d'un signal doit correspondre à la signature de la fente de réception. (En fait, un slot peut avoir une signature plus courte que le signal qu'il reçoit car il peut ignorer des arguments supplémentaires.) Comme les signatures sont compatibles, le compilateur peut nous aider à détecter les discordances de type.

Cependant code comme:

QObject::connect(&source, SIGNAL(MySignal(QByteArray,QString,bool), &sink, SLOT(MySlot(QByteArray,bool)); 

donne une erreur "Incompatible émetteur/récepteur arguments".

Pourquoi cela se produit-il et où est-il documenté que vous devez supprimer les paramètres à la fin? Je comprends qu'avec des conversions implicites, il peut y avoir des problèmes, mais je pensais que QT fonctionnait essentiellement avec des métadonnées qui devraient être capables de raccorder un signal/slot comme ci-dessus.

+0

Un peu d'une question inutile car il peut être facilement fait avec la syntaxe de connexion Qt5 et un lambda. Vous utilisez simplement la mauvaise méthode de connexion. – IlBeldus

Répondre

3

[...] il peut ignorer des arguments supplémentaires. [...]

Il n'y a pas d'autre moyen que l'évidence pour le lire.
Admettre un instant qu'il est techniquement possible (et ce serait un cauchemar pour le faire, croyez-moi) et de considérer la déclaration suivante:

QObject::connect(
    &source, 
    SIGNAL(MySignal(QString,QString,QString), 
    &sink, 
    SLOT(MySlot(QString,QString) 
); 

Jusqu'à présent, si bon. Si Qt a fonctionné comme vous l'avez décrit, quel est le QString à ignorer?
Devriez-vous introduire un ensemble de règles et d'exceptions pour traiter ces cas, afin qu'il mène rapidement l'outil de fente de signal à l'enfer? Ceci étant dit, depuis C++ 11, nous avons des expressions lambda comme partie du langage. Qt5 les a accueillis et a défini un tout nouveau jeu de définitions connect avec lequel vous pouvez faire exactement ce que vous voulez. Par la main. Quand vous en avez vraiment besoin et que vous savez ce que vous faites. Alors que le cadre ne doit pas essayer de deviner quelles sont vos exigences lorsqu'un événement est émis.

+0

Merci, jusqu'à très récemment, nous n'étions pas en QT5 et C++ 11. J'ai toujours du mal à utiliser la nouvelle méthode d'appel de connexion QT5 (sans Lambda), il se plaint d'une "référence indéfinie" à staticMetaObject. Notez que l'ancienne connexion basée sur SIGNAL et SLOT fonctionne correctement au même endroit. –

+0

@RobertDuff Probablement vous n'avez pas dérivé tous les types impliqués de 'QObject'. Ce n'est pas facile à dire sans voir le vrai code. – skypjack

+0

La classe est une interface, mais elle est dérivée de QObject (aucun problème de classement dans les déclarations de classe de base) et implémente la macro Q_OBJECT. Le signal et le destructeur ne sont pas purement virtuels, mais toutes les autres méthodes le sont. Je ne peux malheureusement pas copier et coller du code, ni même modifier l'interface que j'utilise. –