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?