Que penser des frameworks et architectures qui font dériver toutes les classes d'un SuperObjet ?

Salut yan!

Comme je ne comprends pas très bien ce que tu veux dire pour les 3 points que tu cites, pourrais tu donner des petits exemples de codes ? Cela nous parlera mieux à tous.

En ce qui concerne boost, il n'y a pas de difficulté pour connecter/deconnecter des signaux au besoin. Lorsqu'on envoie un signal qui est non connecté, il ne se passe rien tout simplement.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

boost::signals::connection c = sig.connect(HelloWorld()); if (c.connected()) { // c is still connected to the signal sig(); // Prints "Hello, World!" }   c.disconnect(); // Disconnect the HelloWorld object assert(!c.connected());// c isn't connected any more   sig(); // Does nothing: there are no connected slots

---

Etait-ce cela qui te semblait poser problème ?


En terme de capacité, il est vrai que de la même manière Qt me semble (opinion en tant que débutant Qt) beaucoup plus limité que FlowVR (qui permet de faire du multi computer/ multi CPU / multi process / multi thread en encapsulant MPI).

On va bien sûr du plus simple à intégrer (boost avec juste des .h), au plus complexe (FlowVR qui nécessite un bon approfondissement pour comprendre le fonctionnement/l'utilisation :aie:). Un compromis serait de coupler Boost.signal avec Boost.mpi :).

Tout ceci n'a heureusement aucun rapport avec le superobject :ccool:. Peut-être qu'un nouveau thread (dans la partie Qt ou boost) sur le sujet serait plus approprié?

Citation:

---

Envoyé par ElPedro

Comme je ne comprends pas très bien ce que tu veux dire pour les 3 points que tu cites, pourrais tu donner des petits exemples de codes ? Cela nous parlera mieux à tous.

---

Code:

---

connect(w1,SIGNAL(clicked()),w2,SLOT(action1()));

---

Si le slot ou le signal n'existe pas, il y as un message en debug et on continue l'exécution.
Si les types sont incompatibles, il y as un message en debug et on continue l'exécution.

On est pas obligé de connaitre w1 et w2. Il peuvent venir de n'importe où(factory, code, .ui, plugin,...).
Si le connect est impossible es ce obligatoirement une erreur? ca dépend.

Le fait que de base les signal/slot sont couplés au metadata on peut obtenir des choses puissante.
Un exemple :
http://qt.developpez.com/doc/latest/...extfinder.html
Ici il charge un .ui pendant l'exécution. On as aucune idée de ce qu'il contient, puis on fait
QMetaObject::connectSlotsByName(this); et tous ce connect en fonction des nom des instances et des signal/slot.

Un autre :
http://qt.developpez.com/doc/latest/...alculator.html
On charge un .ui et un script qui va le manipuler.

Y as d'autre chose utile autour, comme le sender qui permet d'accéder à l'objet qui à emit le signal.
http://qt.developpez.com/doc/latest/qobject.html#sender

Tu peut déconnecter toutes les connections d'un QObjet, ou en fonction de receveur.

Si un objet est détruit toutes ses connections sont automatiquement supprimées.

Tu peut bloquer temporairement les signaux envoyés par un objet. Par exemple quand tu fait une mise à jour et tu ne veut pas qu'ils envoient de signaux.

Le fonctionnement multithread :
http://qt.developpez.com/doc/latest/...ustomtype.html

Paramétrer le type de connexion : http://qt.developpez.com/doc/latest/...ctiontype-enum

Y as aussi des choses avec DBUS (mais je n'ai jamais testé)
http://qt.developpez.com/doc/latest/...onnection.html

Toutes c'est choses font partie du système de signal/slot de Qt. Si tu les enlève, les signal/slot de Qt ne servent plus à rien ;)

1/
Impressionnant ! On aurait du commencer par là:ccool:
2/
Je vais potasser tout ça. Réponse dans qques jours :mouarf:.