Discussion :

[Nykoo]

Si on a un signal:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void signal(QString&);

Qui est émit à partir de:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void fonction(){
   QString str("test");
   emit signal(str);
}

Si l'instructruction emit signal(str) se comportait comme une fonction classique, QString serait détruit après l'exécution de cette dernière (A la sortie de fonction()). La doc dit:

Execution of the code following the emit statement will occur once all slots have returned.

http://qt.developpez.com/doc/4.3/signalsandslots/

Donc aucun problème quand j'utilise:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

connect(Objet1,SIGNAL(signal(QString&)),Objet2,SLOT(slot(QString&)));

La fonction slot(QString&) recevra bien un référence sur mon objet str temporaire qui existe toujours puisque la fonction qui a émit le signal (fonction()) n'a pas finit son exécution (puisque emit attend que connect() soit exécuté).

Mais:

The situation is slightly different when using queued connections; in such a case, the code following the emit keyword will continue immediately, and the slots will be executed later.

http://qt.developpez.com/doc/4.3/signalsandslots/

Donc le truc c'est de savoir dans quel cas on se situe par défaut quand on utililise la fonction connect(): http://qt.developpez.com/doc/4.3/qobject/#connect
Qt::AutoCompatConnection -> c'est quoi?

Les seuls types expliqués: http://qt.developpez.com/doc/4.3/qt/...ctiontype-enum
Qt:irectConnection
Qt::QueuedConnection
Qt::BlockingQueuedConnection
Qt::AutoConnection

Donc après test ça fonctionne avec le paramètre par défaut Qt::AutoCompatConnection mais c'est peut être un coup de chance. Au pire je pourrais utiliser Qt:irectConnection mais je voudrais savoir si par défaut c'est bon.

[yan]

C'était pour ça ma question
http://www.developpez.net/forums/sho...20&postcount=2
Mais j'y ai pas encore répondu car je n'ai pas eu le temps de vérifier pour etre précis.
Je dirait pour l'instant, qu'il faut faire très attention au pointeur et référence dans un signal. Au mieux faut les proscrire.
T'aura aussi des problème si tu fait ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void fonction(){
   QString str("test");
   emit signal(str);
   str="test2";
}

Ce qui faut savoir est que Qt utilise la méthode de Copy On Write
http://fr.wikipedia.org/wiki/Copy-On-Write. http://qt.developpez.com/doc/4.3/shared/

Donc utiliser une référence sur un objet Qt ne fera pas obligatoirement gagné du temps.

[IrmatDen]

La réponse à cette question est déjà dans la doc:

Qt supports three types of signal-slot connections:

* With direct connections, the slot gets called immediately when the signal is emitted. The slot is executed in the thread that emitted the signal (which is not necessarily the thread where the receiver object lives).
* With queued connections, the slot is invoked when control returns to the event loop of the thread to which the object belongs. The slot is executed in the thread where the receiver object lives.
* With auto connections (the default), the behavior is the same as with direct connections if the signal is emitted in the thread where the receiver lives; otherwise, the behavior is that of a queued connection.

The connection type can be specified by passing an additional argument to connect(). Be aware that using direct connections when the sender and receiver live in different threads is unsafe if an event loop is running in the receiver's thread, for the same reason that calling any function on an object living in another thread is unsafe.

Donc utiliser une référence sur un objet Qt ne fera pas obligatoirement gagné du temps.

En effet, mais le code récepteur sera obligé de n'utiliser que les méthodes const de QString, ce qui est une bonne chose.

[Nykoo]

C'était pour ça ma question
http://www.developpez.net/forums/sho...20&postcount=2

Ok je comprends mieux.

Mais j'y ai pas encore répondu car je n'ai pas eu le temps de vérifier pour etre précis.
Je dirait pour l'instant, qu'il faut faire très attention au pointeur et référence dans un signal. Au mieux faut les proscrire.
T'aura aussi des problème si tu fait ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void fonction(){
   QString str("test");
   emit signal(str);
   str="test2";
}

Le problème c'est si signal prend str par référence je suppose? Dans ce cas si un autre objet récupère str (grâce aux connections) ça sera le même (même emplacement mémoire). D'où le problème avec la modification str="test2" qui fait que l'objet qui a récupéré str verra sont str modifié?

Ce qui faut savoir est que Qt utilise la méthode de Copy On Write
http://fr.wikipedia.org/wiki/Copy-On-Write. http://qt.developpez.com/doc/4.3/shared/

Ok je vais voir ça...

Donc utiliser une référence sur un objet Qt ne fera pas obligatoirement gagné du temps.

Ok

La réponse à cette question est déjà dans la doc:



En effet, mais le code récepteur sera obligé de n'utiliser que les méthodes const de QString, ce qui est une bonne chose.

J'ai vu, mais ça ne m'explique pas quel est le rôle de Qt::AutoCompatConnection

Car c'est bien ça ma question: quel est le comportement des connect() avec Qt::AutoCompatConnection?

[IrmatDen]

J'ai vu, mais ça ne m'explique pas quel est le rôle de Qt::AutoCompatConnection

Car c'est bien ça ma question: quel est le comportement des connect() avec Qt::AutoCompatConnection?

T'occupes, ça fait pas parti de l'interface publique. Et en étant vraiment curieux, tu peux toujours aller voir le code de QObject::connect et constater:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if (type == Qt::AutoCompatConnection) {
        type = Qt::AutoConnection;

Donc, t'occupes; je pense que c'est soit pour des raisons de rétro compatibilité, soit ils se laissent une marge d'évolution pour un futur plus ou moins proche

Edit: donc puisque la doc dit que Qt::AutoConnection est le comportement par défaut, tu peux lui faire confiance.

[Nykoo]

La réponse à cette question est déjà dans la doc:



En effet, mais le code récepteur sera obligé de n'utiliser que les méthodes const de QString, ce qui est une bonne chose.

Je l'entends bien Mais est-ce que avec ce comportement par défaut les connexions sont directes ou à la file?

[yan]

Je l'entends bien Mais est-ce que avec ce comportement par défaut les connexions sont directes ou à la file?

ça depend dans quel thread est executé le receiver

[Nykoo]

ça depend dans quel thread est executé le receiver

Ben apparemment ça dépend juste de l'option que l'on donne à connect():

http://qt.developpez.com/doc/4.3/qt/...ctiontype-enum

Qt:irectConnection : When emitted, the signal is immediately delivered to the slot.
Qt::QueuedConnection : When emitted, the signal is queued until the event loop is able to deliver it to the slot.

Donc là c'est clair c'est cette option qui définie le comportement, mais par défaut connect() est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

QObject::connect ( const QObject * sender, const char * signal, const QObject * receiver, const char * method, Qt::ConnectionType type = Qt::AutoCompatConnection )

Donc ici je n'ai pas Qt:irectConnection ou Qt::QueuedConnection
mais celui par défaut Qt::AutoCompatConnection.

Donc ici Qt::AutoCompatConnection donnera quel comportement?

[IrmatDen]

Dans la doc que j'ai pointé plus haut... Je t'extrait la seule ligne nécessaire à ta question, ce sera plus facile....

* With auto connections (the default), the behavior is the same as with direct connections if the signal is emitted in the thread where the receiver lives; otherwise, the behavior is that of a queued connection.

"The default" veut dire que c'es tle comportement par défaut! Donc le comportement que tu obtiendras est celui décrit dans ce court paragraphe...

[Nykoo]

Je suis désolé j'avais pas vu le bout de code que tu avais posté:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if (type == Qt::AutoCompatConnection) {
        type = Qt::AutoConnection;

Donc du coup je vous comprends mieux et aussi pourquoi Mongaulois parlait des threads.

Merci beaucoup à vous 2.

[yan]

Tien y as ca de trés intéressant a comprendre :
http://qt.developpez.com/doc/4.3/qt/...ctiontype-enum

With queued connections, the parameters must be of types that are known to Qt's meta-object system, because Qt needs to copy the arguments to store them in an event behind the scenes.

[Nykoo]

C'est quoi en fait le système meta-object?

[IrmatDen]

C'est ça: http://qt.developpez.com/doc/4.3/metaobjects/ (c'est cours en plus)

[yan]

Puis ca montre que j'ai encore dit des conneries

Je dirait pour l'instant, qu'il faut faire très attention au pointeur et référence dans un signal. Au mieux faut les proscrire.

[Nykoo]

Donc si j'ai bien compris, les arguments doivent être des éléments dérivés directement (ou indirectement) de QObject?

Pour les pointeurs et références ils sont souvent utilisés dans les signaux/slots des classes de Qt. Pourquoi?
Par exemple le signal: QLineEdit::textEdit(const QString&) utilise une référence alors que QString est une classe partagée (shared class). C'est inutile.

[yan]

Donc si j'ai bien compris, les arguments doivent être des éléments dérivés directement (ou indirectement) de QObject?

Ou un type simple. C'est ce que je comprend. Plus exactement, un type qu'il sait recopier.

Pour les pointeurs et références ils sont souvent utilisés dans les signaux/slots des classes de Qt. Pourquoi?

J'ai regardé un peu, il ne me semble pas avoir vu de signaux/ slot avec des pointeurs. Tu aurais un exemple?

Par exemple le signal: QLineEdit::textEdit(const QString&) utilise une référence alors que QString est une classe partagée (shared class). C'est inutile.

Ça peut éviter la création d'une QString. Mais je suis assez d'accord avec toi. C'est peut être aussi pour faire plus C++, ou pour des optimisations du compilateur..

[yan]

IL explique un peu ici
http://matthieu-brucher.developpez.c...gnal-slot/#LII

[Nykoo]

J'ai regardé un peu, il ne me semble pas avoir vu de signaux/ slot avec des pointeurs. Tu aurais un exemple?

Oui par exemple dans la classe QTreeWidget:
void QTreeWidget::itemClicked ( QTreeWidgetItem * item, int column )
http://qt.developpez.com/doc/4.0/qtr...t/#itemclicked

Je vais voir le lien que tu m'as donné merci.