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.