Discussion :

[jblecanard]

En revanche, je pense qu'obliger toutes ses classes à dériver d'une super classe fragilise l'architecture du logiciel en l'ossifiant et la rendant moins réutilisable.

Ce n'est pas faux, cela dépend aussi de la richesse du super objet en question. De plus, l'utilisation d'un framework implique souvent que le code développé dessus est difficilement réutilisable sans le framework, super objet ou non.

Par contre, je ne vois pas en quoi ça le fragilise ? Parce que le code du super objet impacte sur tout le reste ?

Le second pointe certaines restrictions que peut imposer la technique, au sujet par exemple de l'héritage multiple ou en diamant, avec la nécessité de passer par un héritage virtuel

C'est vrai, mais tant qu'à parler de bonne pratiques, l'héritage multiple est à éviter dans de très nombreux cas, voire interdit dans certains process de développement.

Le troisième est que l'on en arrive à une hiérarchie de classes sur un tel nombre de niveau que l'on finit par avoir des interfaces beaucoup trop complexes pour les classes qui se trouvent "en bas" de la hiérarchie, et pour lesquelles une grande quantité de membres n'ont, en définitive, qu'un intérêt particulièrement limité.

Je ne dis pas que certains membres n'auront aucun intérêt, mais bien qu'ils n'auront qu'un intérêt très restreint dans "l'utilisation quotidienne".

Prenez n'importe quelle classe concrète de Qt, par exemple, et amusez vous à faire le compte de toutes les méthodes, propriétés et membres qu'elles contient, même si on s'en tient à l'interface publique, et amusez vous à réfléchir un peu correctement aux cas dans lesquels vous pourriez y recourir...

Dans de nombreux cas, vous allez limiter l'utilisation de l'interface à quelques méthodes à peine, et un bon 80% du reste ne sera que d'une utilisation marginale.

Je pense que ceci est beaucoup lié au modèle objet et à l'utilisation massive du polymorphisme. Plus le projet est grand, plus ta hiérarchie de classes se creuse, c'est inexorable. De plus, les méthodes que tu n'utilises pas, comme tu dis, sont souvent utilisées par tous les objets qui communiquent avec celui-ci dans le framework, sans que tu ne te serves toi même de ces appels.

C'est un manque du C++, de ne pas disposer de l'interdiction de surcharger une méthote (virtuelle), chose possible en Java avec le mot clé final. Un tel mécanisme réduirait considérablement l'interface effectivement disponible d'un objet au moment ou on le manipule en bas de la chaîne.

L'utilisation dune architecture à base de composants peut répondre à ce problème. D'ailleurs, il y a souvent un super composant de base duquel tous les les autres héritent .

Moi, j'aime bien le principe du super objet, s'il reste léger et qu'il ne contient pas de choix "métier".

En tout cas, la question mérite bien un débat. Des retours d'expériences pros seraient intéressants. Perso je bosse dans une grosse boîte qui édite un soft qui se compte en centaines de millions de lignes de code et... nous avons un super objet . Oui, ça a influencé mes réponses, forcément, puisque je trouve en tant que développeur en bas de la chaîne que ça ne pose de problème nulle part.

Des retours sur l'utilisation industrielle, ou dans un projet open source d'envergure, de la programmation aspect m'intéresseraient grandement. Je m'apprête à mettre en chantier un projet perso assez important, et je vais bien réfléchir à mon archi. Bien que je me sois posé en défenseur du super objet dans cette conversation, je ne suis pas pour autant décidé à m'en servir pour le moment.

[koala01]

C'est vrai, mais tant qu'à parler de bonne pratiques, l'héritage multiple est à éviter dans de très nombreux cas, voire interdit dans certains process de développement.

Je ne nie absolument pas que l'héritage multiple soit une mine de problèmes potentiels, mais de là à le considérer comme une pratique à éviter...

Peut être devrais tu te poser la question de la raison qui justifié son interdiction dans certains process de développement, et tu te rendra la plupart du temps compte que c'est parce que celui qui a pris la décision ne se sentait pas particulièrement à l'aise sur le sujet.

Il faut, de plus, penser au fait que dans le stricte modèle objet, cela peut effectivement mener à des catastrophes, mais que si l'on y ajoute une touche de généricité, la plupart des problèmes peuvent s'effacer complètement...

Je pense que ceci est beaucoup lié au modèle objet et à l'utilisation massive du polymorphisme. Plus le projet est grand, plus ta hiérarchie de classes se creuse, c'est inexorable. De plus, les méthodes que tu n'utilises pas, comme tu dis, sont souvent utilisées par tous les objets qui communiquent avec celui-ci dans le framework, sans que tu ne te serves toi même de ces appels.

Mais justement, le modèle objet montre ici ses limites, qui peuvent être contournées de manière efficace et convaincante si l'on intègre également une approche générique.

Le polymorphisme tel que tu en parle ici ne fait référence qu'au polymorphisme dynamique, or il est possible, en C++ du moins, de l'envisager d'autre manière.

De plus, l'approche qui consiste à estimer que tout doit être capable de communiquer avec tout et dans tous les sens ne me parait pas être réellement efficace.

Il y a, bien sur, certains sens de communication que l'on ne peut éviter, mais si on arrive à les définir précisément et, surtout, à s'en tenir à ceux qui sont réellement indispensables, il est possible d'arriver à une certaine quantité de hiérarchies indépendantes les unes des autres qui soient beaucoup moins complexes.

Au final, on en arrive à quelque chose de bien plus évolutif et plus facile à gérer car on risque beaucoup moins de provoquer une régression en essayant de résoudre un problème donné.

Et, quoi qu'il en soit, il reste malgré tout marginal que, à un niveau de communication donné, on doive avoir recours à... des méthodes héritées de (beaucoup) plus haut dans la hiérarchie.

C'est un manque du C++, de ne pas disposer de l'interdiction de surcharger une méthote (virtuelle), chose possible en Java avec le mot clé final. Un tel mécanisme réduirait considérablement l'interface effectivement disponible d'un objet au moment ou on le manipule en bas de la chaîne.

Je n'ai jamais été réellement convaincu par l'utilité de déclarer une fonction finale... du moins en C++ (parce qu'il faut rappeler que l'optique de java et celle de C++ sur au sujet de la virtualité des fonctions membres sont fondamentalement opposées)

[Mac LAK]

Pour ma part, j'aime au contraire beaucoup cette notion. Faut dire aussi qu'à force de bouffer de la VCL (librairie Borland pour Delphi et C++ Builder), non seulement on s'y habitue, mais on en voit également les avantages... Je ne vois pas vraiment d'inconvénients, en fait, sauf UN SEUL : c'est très bien sur quelque chose d'un minimum pensé à l'avance, c'est par contre "dangereux" sur un système construit de façon incrémentale de façon un peu anarchique.

[jblecanard]

Globalement Koala, je suis pas mal d'accord avec toi.

Le polymorphisme tel que tu en parle ici ne fait référence qu'au polymorphisme dynamique, or il est possible, en C++ du moins, de l'envisager d'autre manière.

A quoi penses-tu au juste ?

Je n'ai jamais été réellement convaincu par l'utilité de déclarer une fonction finale... du moins en C++

En fait, c'est plus organisationnel que technique. C'est utile pour empêcher les développeurs du dimanche (comme moi ) de tromper les objets de bas niveau en héritant de classes qui ne devraient pas l'être et en surchargeant des méthodes virtuelles qui ne sont pas censées les concerner. Je l'accorde c'est sans doute se disperser et s'écarter du problème discuté.

[Goten]

A quoi penses-tu au juste ?

Polymorphisme adhoc (surcharge/coercition), polymorphisme paramètrique (le meilleur ... :p)

Quant à l'héritage multiple, il est certes à utiliser avec précaution, mais aussi très puissant. (je pense notamment aux classes de politiques / de traits qui utilisent fortement l'héritage multiple).

[koala01]

A quoi penses-tu au juste ?

Allez, un petit tour du coté de la FAQ et des réponses suivantes pour te donner une idée de ce à quoi je pense...

Il faut avouer que tout n'est pas forcément adapté pour tous les langages, mais, bon dieu, le C++ est un langage multi paradigmes... Pourquoi ne pas en profiter

En fait, c'est plus organisationnel que technique. C'est utile pour empêcher les développeurs du dimanche (comme moi ) de tromper les objets de bas niveau en héritant de classes qui ne devraient pas l'être et en surchargeant des méthodes virtuelles qui ne sont pas censées les concerner. Je l'accorde c'est sans doute se disperser et s'écarter du problème discuté.

En java, tu n'a pas le choix: une fonction est, par défaut virtuelle.

En C++, par contre, c'est l'inverse: une fonction est par défaut non virtuelle, et tu dois explicitement indiquer qu'elle l'est si tu veux qu'il en soit ainsi.

Si une fonction ne doit pas être redéfinie, déclare la non virtuelle, basta... Tu y gagnera en outre peut-être une vtable...

Bon, après, je t'accorde que, si une fonction est virtuelle, il *peut* être intéressant d'interdire qu'elle ne soit d'avantage redéfinie... Mais est-ce à toi d'en juger

Peut tu avoir la certitude que l'utilisateur de ta classe ne voudra pas en faire hériter une des siennes

N'est-ce pas imposer un choix qui ne t'appartient pas de faire

[jblecanard]

Polymorphisme adhoc (surcharge/coercition), polymorphisme paramètrique (le meilleur ... :p)

Ha oui d'accord mais à chaque polymorphisme son utilité . On ne peut pas tout faire avec un seul d'entre eux. Mais moi aussi j'aime manger des templates et le paramétrique, ma foi, que ferait-on sans lui ?

Peut tu avoir la certitude que l'utilisateur de ta classe ne voudra pas en faire hériter une des siennes

N'est-ce pas imposer un choix qui ne t'appartient pas de faire

En tant que concepteur de l'architecture bas niveau d'un système, oui, je considère que, dans une optique de qualité, ce choix m'appartient. ça ne veut pas dire tout fermer, mais fermer ce que je juge "interne" et qui se retrouve exposé à l'utilisateur par transitivité de l'héritage public.

Une fois encore, tout celà dépend énormément du projet concerné. Dans le cas d'un framework (puisque c'est le sujet initial ), je pense que cen'est en rien gênant, car l'utilisateur du framework se rend automatiquement dépendant de celui-ci, super objet ou non, et ça ne veux pas dire qu'il est obligé de faire descendre tout ses objets du SuperObject fourni par le framework.

En fait la question a un double tranchant : est ce qu'on se la pose en tant qu'utilisateur du framework ou en tant que concepteur ?

Je vois un avantage à ne PAS utiliser de super objet dans une architecture : dans le cas ou on s'interface avec plusieurs frameworks différents, il y a un travail d'interfaçage en moins, et pas de double gestion du cycle de vie (ou autre utilisation du super object) à la fois dans l'archi et dans le framework si celui-ci en fournit une.

[koala01]

En fait la question a un double tranchant : est ce qu'on se la pose en tant qu'utilisateur du framework ou en tant que concepteur ?

Le fait est qu'il est aberrant de considérer un framework uniquement en tant que concepteur...

A la base, lorsqu'il s'agit de concevoir un framework, c'est, fatalement pour répondre à un besoin.

Si tu ne l'aborde pas au minimum de ton point de vue en tant qu'utilisateur, qui d'autre pourra le faire

Si, aussi bien soit il conçu, ton framework est inutilisable, les utilisateurs se tourneront sans l'ombre d'un remords vers la concurrence, fut-elle de moindre qualité, si, à l'usage, elle fournit quelque chose de plus facile.

Un utilisateur n'a "que l'embaras du choix" du framework qu'il utilise... un framework sans utilisateur ne sert à rien

[jblecanard]

Le fait est qu'il est aberrant de considérer un framework uniquement en tant que concepteur...

Si tu ne l'aborde pas au minimum de ton point de vue en tant qu'utilisateur, qui d'autre pourra le faire

Oui, à ceci près que c'est à sens unique : l'utilisateur peut ne pas vouloir se poser en concepteur.

Donc est la question peut être :
- "Est ce que créer un super objet est bien pour mon archi ?"
ou
- "Est ce qu'utiliser un framework à super objet est bon ou non ?"

Et là je me rend compte que la question est la même. Il me suffisait de l'écrire pour le voir.

[yan]

Mais le fait est qu'avec du C++ moderne on peut faire mieux.

pour les signaux? les meta data? autres?

[r0d]

Bonjour,

Pour donner mon avis, en 2 points:
1. Cette technique a des avantages et des inconvénients. Ils ont été déjà cité ici, je n'y reviendrai donc pas. Ainsi donc, dans certains contextes elle peut être très bien. Je pense notamment à une lib sur laquelle j'ai travaillé récemment, qui fourni un ensemble de structures pour stocker et manipuler des "objets statistiques" (bon c'est un peu long à expliquer), qui héritaient tous d'un god_object, et c'était parfait: le god_object proposait une interface de sérialisations plus quelques opérations génériques utiles dans tous les objets qui en héritent.
Mais on voit bien, dans cet exemple, qu'il s'agit d'une lib très spécialisée.

2. Pour moi, le principal problème du god_object c'est la réutilisation de code. Je me rends compte, avec l'expérience, la puissance d'une conception bien modulaire. Autrement dit, la puissance du copier/coller. Le bonheur de d'intégrer à son projet des classes d'un autre projet sans avoir rien à modifier.
Par exemple, je me trimballe partout ma "lib perso", qui implémente tout un tas de fonctionnalités qui sont très utiles et fréquentes dans la branche dans laquelle je travaille, et je suis constamment en train de copier des bouts de code de cette lib, sans avoir à le modifier, c'est que du bonheur.

[koala01]

Oui, à ceci près que c'est à sens unique : l'utilisateur peut ne pas vouloir se poser en concepteur.

Et pourtant il se posera de toutes manières en concepteur de quelque chose... c'est le propre d'un framework

Un framework n'est jamais qu'une collection de briques de base, plus ou moins bien agencées, plus ou moins "bien foutues" qui tend à faciliter la vie de l'utilisateur pour lui permettre de répondre à ses propres besoins... qui ne seront sans doute jamais exactement ceux auxquels pourraient avoir pensé les concepteurs du framework

Donc est la question peut être :
- "Est ce que créer un super objet est bien pour mon archi ?"
ou
- "Est ce qu'utiliser un framework à super objet est bon ou non ?"

Et là je me rend compte que la question est la même. Il me suffisait de l'écrire pour le voir.

Et là, nous nous heurtons de plein fouet à "la philosopie de l'utilisateur"...

Il faut bien te rendre compte que, comme le framework fournit "les briques de base", la philosophie qui aura prévalu au moment de sa conception ne peut pas faire autrement que de... laisser une empreinte forte sur la manière dont il est utilisé...

L'utilisateur se trouve donc confronté à trois possibilités:

• Soit la mentalité lui plait, et tout va très bien
• Soit la mentalité lui déplait, et il va "voir ailleurs"
• Soit la mentalité lui déplait, mais elle lui semble "moins mauvaise" que la concurrence, et il décide d'utiliser malgré tout le framework

Et il va de soi que, quand je parle de mentalité, ce n'est pas uniquement du point de vue de la conception, mais que l'on peut prendre en compte la licence sous laquelle le framework est présenté / disponible...

C'est sans doute à de telles considérations d'ordre générale que Qt doit son succès malgré le fait que l'utilisation de moc et autres joyeusetés fasse qu'il est difficile à prendre en main et à utiliser en comparaison de la VCL ou d'un VS complet...[EDIT]Même si c'est plutôt du à une question d'intégration des outils dans les RAD [/EDIT]

[Laurent Gomila]

pour les signaux? les meta data? autres?

Les deux. Evidemment, la définition de "mieux" ici dépend de mon point de vue, certains ne verront pas forcément d'avantages flagrants aux solutions alternatives qui sont proposées.

[yan]

Les deux. Evidemment, la définition de "mieux" ici dépend de mon point de vue, certains ne verront pas forcément d'avantages flagrants aux solutions alternatives qui sont proposées.

tu as des exemples?
ça m'intéresse d'avoir des points de comparaison.
Pour les signaux, je n'ai actuellement rien vue d'aussi puissant que ceux fournie pas Qt. Particulièrement dans un contexte mutithread.

[Luc Hermitte]

C'est vrai, mais tant qu'à parler de bonne pratiques, l'héritage multiple est à éviter dans de très nombreux cas, voire interdit dans certains process de développement.

Le truc est que tant que le LSP n'est pas compris, il est difficile d'utiliser l'héritage multiple sous de bonnes conditions -- et en fait l'héritage simple aussi.

En fait, c'est plus organisationnel que technique. C'est utile pour empêcher les développeurs du dimanche (comme moi ) de tromper les objets de bas niveau en héritant de classes qui ne devraient pas l'être et en surchargeant des méthodes virtuelles qui ne sont pas censées les concerner. Je l'accorde c'est sans doute se disperser et s'écarter du problème discuté.

Pattern NVI ?
Il vise à dissocier les fonctions que l'utilisateur doit connaitre des fonctions dont le concepteur peut raffiner le comportement.
Et combiné avec l'héritage multiple, on a des interfaces bien plus propres que les interfaces vides de Java/COM/CORBA/....


Sinon, je n'aime pas du tout les god_objets. Je les considère comme des void* qui perdent le typage -- et qui ne peuvent rien nous apporter sur les objets à sémantique de valeur si jamais on voulait profiter des services "divins" de ce void*. Quant aux soit-disant avantages, ils sont concurrencés par d'autres approches mieux typées et tout aussi fonctionnelles (boost.signal, boost.serialize, la lib de Laurent pour la réflexion, ...)
Qt s'en sert ? Et ? Je préfère toujours la conception d'Adobe.ASL -- même si tout laisse à croire aujourd'hui que cette lib ne sera jamais utilisable en production en dehors de chez Adobe.

[Laurent Gomila]

tu as des exemples?
ça m'intéresse d'avoir des points de comparaison.
Pour les signaux, je n'ai actuellement rien vue d'aussi puissant que ceux fournie pas Qt. Particulièrement dans un contexte mutithread.

J'avais donné des exemples dans mon premier message.

Les signaux Qt sont très limités et loin d'offrir le même niveau de flexibilité que boost.signal. Je hais être forcé d'utiliser un précompilateur, et je trouve leur système de connection trop rigide (impossible de connecter autre chose que des fonctions membres de QObject qui ont exactement le même prototype -- la seule liberté que l'on ait c'est d'avoir moins de paramètres que le signal dans le slot). On se retrouve bien souvent à implémenter des slots intermédiaires juste pour adapter l'appel, ou à utiliser des choses plus compliquées prévues uniquement pour contourner cette limitation, du genre QSignalMapper.
Avec boost.signal je peux connecter n'importe quoi n'importe où, sans précompilateur.

Pour ce qui est de l'aspect multithreadé, j'imagine que la plupart des problèmes sont résolus parce que les signaux passent par des files plutôt que d'être envoyés directement, ce qui n'est pas difficile à implémenter par dessus n'importe quel système de signaux/slots.

[Goten]

+1 avec Laurent pour la facilité et la flexibilité (hérité de boost.function) de boost.signal et je rajouterais que sur l'aspect MT, signal2 est thread safe ...

[Invité]

Qt s'en sert ? Et ?

Qt s'en sert parce que sa hiérarchie de classe est très fortement influencée par la VCL de Borland. Au début du siècle, Borland et Trolltech avaient collaboré pour la création de Kylix, la version Linux de Delphi, et les classes de Qt ressemblent énormément à la CLX de Borland (portage de la VCL).

Je suis également très influencé par Borland, mais j'avoue trouver ces hiérarchies de classes pyramidales très pratiques pour le développement d'IHM. La classe dont on dérive un composant graphique standardise son interface, et le rend facilement remplaçable. En développement d'IHM, c'est très important.

Egalement, le fait d'avoir une hiérarchie unique, si possible sans trop de branches, permet de gérer assez naturellement des pattern composite (widget contenant des widgets), très communs en IHM.

Enfin, l'utilisation d'un référentiel commun permet souvent de fédérer une équipe projet.

Au total, une fois qu'on maîtrise les classes de base, le développement devient assez rapide et intuitif, et les programmes sont rendus homogènes par cette hiérarchie commune. Le prix à payer, c'est bien sur le fait qu'il faut développer en "allant dans le sens du framework" (essayer de lutter contre, c'est une folie), et la présence d'idiomes pas trop élégants (on passe un peu son temps à caster dans des types parents plus ou moins généraux, et à vérifier des types à l'exécution).

Mais j'ai l'impression que ces méthodes ont plutôt fait leurs preuves, et je ne suis pas convaincu du besoin d'une alternative...

Je n'en vois pas trop l'utilité en dehors de l'IHM...

Francois

[gbdivers]

Pour résumé les débats jusqu'ici... on a des défenseurs dans le 2 camps, tous ont des arguments intéressants. Au final, le choix dépendra fortement du concepteur de l'architecture, ses affinités personnelles avec les techniques utilisées et de ce qu'il veut offrir aux utilisateurs ou aux autres développeurs.

En voyant le niveaux des intervenants (beaucoup de rédacteurs et/ou spécialistes) et les notions de c++ abordées (qui me semblent être d'un niveau élevé), je me pose la question du niveau général de maîtrise de ces notions et du temps nécessaire pour former correctement quelqu'un la dessus.

Mon expérience personnelle sur le niveau des étudiants en informatique en C++ n'est pas fameuse. Au niveau BTS informatique, ceux que je connais débutent le C++, connaissent mal la POO et pensent que les templates sont pour les experts en c++. Au niveau M1, le niveau théorique est (forcement) plus élevé mais les notions plus complexe et la maîtrise n'est pas encore là (manque d'expérience).

Comme le choix de l'utilisation des super-objets est un choix de facilité de conception, il me semble important de se poser la question du niveau requis (et de la facilité de recrutement) pour développer avec ou sans ces super-objets.
Les questions que je me pose peuvent donc être schématisées par des graphiques, avec en abscisse le niveau de difficulté des notions utilisées (par exemple, par ordre croissant de difficulté : C with object, C++ objet, template, pattern, généricité, etc.), et en ordonnée :
1. la proportion d'utilisation dans des applications/framework (propriétaire ou "publique")
2. le niveau de formation et/ou le temps de formation nécessaire pour connaître/comprendre/maîtriser ces notions (par exemple, combien de temps faudra-t-il pour que quelqu'un se forme pour utiliser les signaux/slots de Qt ? et les signaux/slots de boost ?)
3. la proportion de population (chez les développeurs) maîtrisant ces notions
En d'autres termes, si je choisit d'utiliser un concept en particulier, quel sera la difficulté de trouver et de former une équipe le maîtrisant (ce qui influencera la survie à long terme du projet). Questions subsidiaires : quel est la proportion de personnes utilisant boost ? tr1 ? tr2 ? C++0x ?


Ces questions me semblent importantes pour choisir a priori, lorsque l'on démarre un projet, du niveau technique que l'on peut accepter.
J'imagine, par exemple, qu'un projet lancé par une entreprise qui peut mettre les moyens pourra se permettre d'embaucher un spécialiste du c++ sur du long terme qui pourra assurer la continuité.
Sur un gros projet "publique" qui rassemblera un nombre suffisant de développeurs, on arrivera toujours à rassembler suffisamment de spécialistes au cours du temps, malgré les aléas des départs et arrivées.
Sur un projet plus petit (de l'ordre de 20 développeurs par exemple), le choix des super-objets peut se révéler être le plus performant, compte tenu des changements rapides dans l'équipe de développement.

EDIT: mon message a croisé celui de fcharton. Je te rejoint pour l'intérêt des super-objets dans les ihm. Je pense qu'on peut étendre l'utilisation de ces super-objets à toutes les structures composites. Je pense par exemple à QScript ou au QML, qui peuvent utiliser des objets C++ et qui nécessitent donc que les objets C++ manipulés aient une base commune.

[yan]

J'avais donné des exemples dans mon premier message.

je pensais que tu en avais d'autre exemple que boost.

Les signaux Qt sont très limités et loin d'offrir le même niveau de flexibilité que boost.signal. Avec boost.signal je peux connecter n'importe quoi n'importe où.

vrai. Mais là où boost veut être générique (du simple appel de fonction), Qt se spécialise sur son architecture à base d'eventloop et d'organisation hiérarchisé des QObject. Appeler une fonction dans cette architecture ne veut rien dire. Sauf si on mélange encore le C et le C++....
Qt ne cherche pas à être boost et rien n'empêche d'utiliser les deux.

Je trouve leur système de connection trop rigide (impossible de connecter autre chose que des fonctions membres de QObject qui ont exactement le même prototype -- la seule liberté que l'on ait c'est d'avoir moins de paramètres que le signal dans le slot).

Que veut tu dire par prototype?

On se retrouve bien souvent à implémenter des slots intermédiaires juste pour adapter l'appel, ou à utiliser des choses plus compliquées prévues uniquement pour contourner cette limitation, du genre QSignalMapper.

C'est dommage qu'il n'ai pas encore proposé une solution plus propre pour cela. Mais c'est surement pas aussi simple que tu le pense.

+1 avec Laurent pour la facilité et la flexibilité (hérité de boost.function) de boost.signal et je rajouterais que sur l'aspect MT, signal2 est thread safe ...

l'aspet thread safe n'est pas la même en Qt et boost. A moins que je me trompe, signal2 permet d'utiliser le même signal par plusieurs thread en même temps. Mais l'appel est toujours directe.

Pour ce qui est de l'aspect multithreadé, j'imagine que la plupart des problèmes sont résolus parce que les signaux passent par des files plutôt que d'être envoyés directement,

c'est le contraire, c'est le slot qui est exécuté au travers de son eventloop. Et c'est là ou je dit que la version de Qt est plus puissante.
1- chaque QObject appartienne à un thread.
2- lors qu'un signal est émit:

• signal et slot dans le même thread : appel direct comme le ferais Boost
• signal et slot dans des threads différents : le signal post un event dans l'eventloop du sot pour qu'il l'éxécute. Il y as copie des paramètres bien sure (compensé généralement par le COW et attention au pointeur).

Et ça c'est automatique (par défaut). Si tu veut mettre un QObject dans un thread, t'as pas à gérer la gestion du multithreading si tu utilise les signal/slot de Qt. Et dans la plupart des cas, finie les mutex & co.

ce qui n'est pas difficile à implémenter par dessus n'importe quel système de signaux/slots.

Et tu réinvente la roue...Et avoir une eventloop performante et threadsafe c'est pas si simple.
A ma connaissance seule Qt propose ce type de fonctionnement.

Autre points :

• Si un QObject est détruit, toutes ses connexions sont automatiquement supprimé.
  
• Qt as fait le choix de faire des connexions dynamique au lieu de statique. Cela permet des choses comme les auto-connect mais cela oblige d'attendre l'exécution pour savoir si un connect est faux...

Et non Qt n'est pas la solution et je pense qu'il faut arrêter de l'idéaliser.


Pour le superObject, je pense cela permet de construire une base robuste et saine pour de gros framework comme Qt et que c'est nécessaire , mais inutile dans la plupart des autres cas.