Discussion :

[Laurent Gomila]

-une variable de version pour le SuperObject.

De version de quoi ? Une version peut être utilisée pour de nombreuses choses, et il vaudrait mieux gérer ça dans une base séparée du genre Serializable (si c'est pour ça que tu veux une version). Note que pour la sérialisation, boost a bien prouvé qu'une classe de base n'était pas nécessaire et qu'on pouvait même faire du non-intrusif.

-une variable de version pour le l'Object qui en herite.

Quid des objets qui intercaleront des classes de base supplémentaires ? Elles devront chacune définir leur propre version, faire ce que tu décris reviendrait à documenter (implicitement) le fait qu'une dérivée d'Object n'est pas censée être elle-même dérivée. Ce qui n'est pas le cas j'imagine.
Et quid des objets qui dériveraient de plusieurs Object ? Plusieurs numéro de version, pas bien non plus.
Laisse donc le numéro de version dans la classe qui l'utilise directement, ce sera bien mieux.

les includes géneriques (Classe de logging, ect...)

Rien de mieux pour allonger inutilement le temps de compilation. On ne devrait jamais privilégier une solution moins bonne techniquement pour épargner quelques lignes de code.

[yan]

Rien de mieux pour allonger inutilement le temps de compilation.

es ce si quantifiable? (je sais pas)

On ne devrait jamais privilégier une solution moins bonne techniquement pour épargner quelques lignes de code.

une question que je me posais (j'en suis pas persuadé mai bon ça reste dans le cadre de la discution).
Dans le cas ou la contrainte est le temps. Es ce que l'on ne peut pas se dire qu'en utilisant un superObject, pour donner un ensemble de fonctionnalité à certaine classe comme l'exemple de ddrmax, ne pourrais pas faire gagner du temps?

[Laurent Gomila]

es ce si quantifiable? (je sais pas)

Ca dépend du projet. Ca peut être significatif sur les gros projets, surtout si la plupart des classes dérivent du super-objet.

Dans le cas ou la contrainte est le temps. Es ce que l'on ne peut pas se dire qu'en utilisant un superObject, pour donner un ensemble de fonctionnalité à certaine classe comme l'exemple de ddrmax, ne pourrais pas faire gagner du temps?

Ca peut, ou pas. Là encore ça dépend beaucoup du projet.

Et tu n'as pas réagi aux exemples de frameworks n'utilisant pas de super-objet qu'on t'a donné

[yan]

Et tu n'as pas réagi aux exemples de frameworks n'utilisant pas de super-objet qu'on t'a donné

J'avais pas vue ta phrase sur Ultimate++, tu as fait un edit?. Je vais regarder cela de plus prés.

Pour asl si j'ai bien compris, l'ihm se monte à partir de script (adam et eve), c'est bien cela?

[ElPedro]

==============

Es ce que l'on ne peut pas se dire qu'en utilisant un superObject, pour donner un ensemble de fonctionnalité à certaine classe comme l'exemple de ddrmax, ne pourrais pas faire gagner du temps?

Je pense que MIRROR est bien plus utile car elle fournit tout le metadata sans avoir besoin d'hériter ni de changer le .h d'une classe déjà existante. Chaiscript permet aussi d'obtenir l'introspection et le scripting sans faire d'héritage (et je pense bien plus dans un proche avenir ). Ces éléments me semblent primordiaux vis-à-vis des fonctionnalités qui semblent t'intéresser. Par contre je ne vois absolument pas en quoi un superobject peut permettre d'accélérer le dev d'un système de communication asynchrone : Admettons que j'ai un superobject 'parfait'. D'après ce que tu dis, il suffirait d'en hériter pour avoir la serialization, le metadata, la communication asynchrone etc.. grâce aux fonctionnalites de la classe mere. Perso cela ne me semble pas du tout faisable. C'est à dire que je considère qu'il faudra ajouter des macros ou un générateur de code en + pour obtenir ces fonctionnalités même si elles sont déjà présentes dans la classe mère.

Or si l'on souhaite obtenir ces fonctionnalité dans un système sans superobject, il faudra aussi écrire ces macros (ou les fonctions correspondantes à la main cf boost::serialize, ou les template correspondants). Bref le choix "super object présent ou pas" n'est pas ce qui va te demander du travail.

Existe-t-il un framework avec un super-object permettant d'ajouter de telles fonctionnalités juste en héritant??
==============

Par ailleurs, est-ce qu'on parle que des framework orientés création de GUI, ou alors tout ceux qui permettent d'écrire des applications conséquentes ?
Car pour les GUI, il me semble que le design pattern composite est effectivement une manière traditionnelle de résoudre le problème. Ce qui peut biaiser le problème.

Sinon je cite boost, dlib (qui contient de la gui) comme excellent frameworks, WildMagic (moteur de jeu complet), le cryengin (c'est un moteur de jeu aussi), mais tu peux fabriquer aussi des framework comme ogre + boost + bullet + mygui (qui contient donc de la gui). De tous , seul boost ne contient pas de gui nativement à ma connaissance, si ce n'est celle qui est générée automatique en tcltk par la librairie d'introspection MIRROR (comme un property tree).

==============

En ce qui concerne les performances, Qt explique que les sig slot templates seraient plus rapide sur leur page d'aide, mais qu'ils préfère garder un MOC pour avoir + de flexibilité et de sécurité dans leur solution. Et cela n'a donc aucun rapport avec le fait d'avoir un superobject ou non. Qui plus est, j'ai lu des témoignages (sur ogre3d, user : nullsquared? je crois) utilisant boost pour remplacer les sigslots de QT (apparemment qt le permet?), justement pour ces raisons de performances.

==============
Note : je suis un méga débutant en qt. Et j'ai peu d'expérience avec les guis. Je connais plutôt les systèmes (3D) asynchrones distribués et la metaprog c++.

[gb_68]

Bonjour,

Qu'est ce qu'un superobject ?
1 seul objet dont hérite toutes les classes (y compris integer, char, vector2d, etc...).

Je ne pense pas qu'absolument tous les types doivent forcément hériter du superobject. Si l'on regarde les autres langages ayant un tel objet en natif, ce n'est souvent pas le cas. En Java, il y a par exemple les types primitifs ; en Delphi tous les objets déclarés avec le mot clé "class" dérive de TObject, mais pas les autres types (primitifs, record ~struct C) ; même C#, il y a une différentiation entre types "valeurs" et types "références". Si le langage fait hériter en apparence les types "valeurs" du SuperObjet (Object) - ce que je trouve plutôt moche -, il y toujours un Boxing pour le passage valeurs->références et les types valeurs n'embarquent pas leur RTTI. Il me semble que le langage D suit aussi cette voie.

Les différents frameworks évoqués plus haut ont je crois aussi pris cette approche lorsqu'ils emploient un "SuperObjet" : les types primitifs/POD/à sémantique valeur n'en héritent pas.
Si SuperObjet il devait y avoir en C++, il ne serait que pour les classes ayant des RTTI embarqués (donc avec au moins un membre virtuel et l'option RTTI activé).

Son intérêt ? euh...
Si quand même peut-être. Si Boost any à une raison d'exister, c'est qu'un besoin de conteneur universelle peut parfois apparaître. Hors any à quelques limites aussi :

A vrai dire, j'ai du mal à trouver mon bonheur dans l'existant. Les composants boost ( variant et any, avec any_cast et lexical_cast ) sont plutôt merveilleux. Seulement, je les trouve d'un peu trop bas niveau. Aussi, le fait de lever une exception pour connaître le type "réel" de "any", où lorsqu'un "lexical_cast" ne passe pas, me déplait.

En fait le C++ possède déjà quasiment tous les pré-requis pour implémenter ce SuperObjet ; avec les RTTI activés, il est possible d'obtenir via typeid les informations réels du type (enfin son nom) et via dynamic_cast sa parenté vers un autre type.
C'est globalement tout ce qu'on attend du SuperObjet et tous les types usant du "polymorphisme d'inclusion" (avec un membre virtuel) supportent déjà ces opérations... il ne manque que le conteneur commun .

Template et autres polymorphismes se résolvant à la compilation - au pire complété par des "type erasure" - suffisent souvent (en tout cas pour mes besoins) mais parfois ...

[yan]

C'est à dire que je considère qu'il faudra ajouter des macros ou un générateur de code en + pour obtenir ces fonctionnalités même si elles sont déjà présentes dans la classe mère.

c'est certainement le but du moc.

En ce qui concerne les performances, Qt explique que les sig slot templates seraient plus rapide sur leur page d'aide, mais qu'ils préfère garder un MOC pour avoir + de flexibilité et de sécurité dans leur solution. Et cela n'a donc aucun rapport avec le fait d'avoir un superobject ou non. Qui plus est, j'ai lu des témoignages (sur ogre3d, user : nullsquared? je crois) utilisant boost pour remplacer les sigslots de QT (apparemment qt le permet?), justement pour ces raisons de performances.

Qt ne cherche pas à être le plus performant en tout mais d'être suffisant. Si les signal/slot sont moins rapide c'est aussi parce qu'ils font plus de choses, comme sont fonctionnement inter-thread ou la possibilité de faire des connexion automatique.
Comme l'utilisation de boost n'entre pas en conflit avec Qt, cela ne pose aucun problème.
Un petit tuto Qt et boost:
http://irmatden.developpez.com/tutor...boost-signals/

Si on prend chaque concept séparément, le superObject n'est pas utile. Mais dés que l'on commence à les regrouper et à les faire interagir pour les étendre, la classe mère me parait beaucoup plus adapté. Peut être que je me trompe sur l'obligation du superObject pour le cas de Qt. Mais c'est ce qui le rend facile à comprendre et à exploiter.

J'ai regardé utimate++. Ell as l'aire vraiment très bien. Mais contrairement à Qt , elle me semble prévue pour un fonctionnement très statique. Si on regarde ce qu'ils écrivent dans la page de download

Based on strictly deterministic design it provides an alternative to GC collected platforms.

Le but n'est pas le même pour moi.

Pour asl, j'ai du mal à comprendre comment elle marche. Mais je n'ai pas vue , non plus, l'équivalent du fonctionnement dynamique que propose Qt.

[edit]
un truc intéressant sur QObject
http://cartan.cas.suffolk.edu/oopdoc...e/qobject.html

[koala01]

Le fait est que, dans le cadre d'une IHM, les types d'objets sont clairement déterminés à la compilation, et qu'il n'y a donc pas vraiment nécessité de donner l'opportunité de décider à l'exécution quel type sera créé en fonction de "l'endroit où aura cliqué l'utilisateur".

Même si tu prévois un certain dynamisme (autre que les habituelles possibilités de redimensionnement) au niveau de ton interface (possibilité d'ouvrir ou de refermer un onglet, de déplacer une barre d'outils, d'ajouter un(e série de) champs dans un formulaire, ...) le type de tout ce qui sera créé / détruit / affiché / utilisé est clairement défini avant même d'en arriver à l'étape de compilation.

Il en découle que toutes les relations entre les différents types sont, elle-aussi, clairement définies, et que, par conséquent, le super objet n'apporte rien, hormis l'interface qu'il propose ...

Mais l'héritage public d'un type non template n'est très clairement pas le seul moyen de récupérer une interface et peut aller jusqu'à mener à des catastrophes lorsque l'on se trouve dans une situation d'héritage en diamant.

[yan]

Même si tu prévois un certain dynamisme (autre que les habituelles possibilités de redimensionnement) au niveau de ton interface (possibilité d'ouvrir ou de refermer un onglet, de déplacer une barre d'outils, d'ajouter un(e série de) champs dans un formulaire, ...) le type de tout ce qui sera créé / détruit / affiché / utilisé est clairement défini avant même d'en arriver à l'étape de compilation.

Pas forcement. Par exemple Qt Creator est principalement(exclusivement?) constitué de plug-in. Et c'est ces plug-in qui forme l'ihm. De base QtCreator ne fait absolument rien.

Qt permet des choses totalement dynamique. Comme charger un .ui au cour de l'exécution. Créer les connections de manière automatique (sans aucun connect écrit dans le code). De créer et supprimer les connections à la volé. De stopper l'envoie de signaux d'un objet pendant un certain temps. De manipuler les objets (création,destruction,... de l'ihm ou autre) par un script. Un exemple intéressant et l'ajout de widget Qt (ihm + fonctionnement) dans une page web :
http://qt.developpez.com/tutoriels/i...iciels-webkit/

Avec le webkit, Qt permet de faire des applications hybride assez simplement.

Et avec QML cela ira encore plus loin (si je me trompe pas c'est similaire à adam & eve de asl).

Toute l'ihm(avec les animations et interactions) sera spécifié dans un fichier chargé à la volé. Tu peut même y ajouter du script pour faire une application entière juste avec cela.

Le but est très différente. Peut être que tous cela aurai pu se faire sans superObject. Mais j'ai vraiment du mal à concevoir comment. Et c'est le seule cas à ma connaissance où je trouve vraiment important d'avoir ce superObject.
J'aurais pensé que c'était aussi le cas pour les sceneGraph (comme OpenInventor), mais orgre3D semble très bien s'en passer.

[ElPedro]

Je te rassure, faire des ajouts de sigslots ne pose pas de soucis techniques particuliers pour les plugins et idem pour le reste pourvu que le framework ait été conçu correctement (avec ou sans superobject).

C'est un chouette exemple les plugins en fait.
Si je reprends les choses par la base :

Disons que j'ai une classe "Habitant". Et un peu plus tard, j'ai des "Habitants Gros" et des "Habitants Maigre". Et encore plus tard des "Habitants Grands" et "Habitants Petit". Quand on cherche à concevoir un fichier évolutif avec plein de classes de ce type comment on s'y prend ? Et bien d'abord on fait pas de superobject, sinon ça va pousser l'utilisateur à faire des héritages inutiles et dangereux, style "Habitant Petit" hérite de "Habitant" etc... Je trouve que le superobject encourage ce type de conception et c'est une des choses qui me chagrine le plus.

La solution est naturellement la suivante:

Habitant
<>-aggrége des-----Capacités

Capacités
<----dont hérite---Taille (dont hériterons grand et petit)
<----dont hérite---Volume (dont hériterons gros et maigre)
<---- et on peut en ajouter...

Aucun superobject à l'horizon et dans le même temps une super variabilité, flexibilité, extensivité, et une grande clarté. Il n'est pas possible non plus de se mélanger les pinceaux entre les classes.

Ensuite il suffit de compléter les fonctions héritées correspondantes (souvent init/destroy/update(dt) dans les prog temps réel), et on peut fabriquer autant de plugin qu'on veut.

Maintenant si je reviens dans le cadre d'un framework + éloigné du cas d'école, dans le cadre d'un système comme ogre3d (qui propose des extensions selon une multitudes de types de plugins), les fonctionnalités proposées entre un plugin de "movable object" et celles d'un "rendersystem" n'ont absolument rien à voir.

Le débutant en informatique serait tenté de manipuler des superobjects dans ses déclarations au lieu des classes précisément concernées (rendersystem et movableobject). D'où le drame potentiel si le superobject est autorisé (car il est potentiellement possible de livrer une dll d'un type incompatible avec celui attendu, le dynamic_cast echouera dans la dll, même si les fonctions sont identiques entre les objets (init/destroy/update))).

//=================
Sinon si l'on souhaite voir des créations de classes dynamiques, manipulations d'attributs etc... Et bien cela n'existe pas vraiment, mais cela se simule. On peut avoir le sentiment d'avoir des éléments complètement dynamique, mais je suis presque certain que tous les frameworks font :
1/ soit de la simulation (ex avec chaiscript), c'est a dire en déclarant une classe 'metadata' et en la manipulant (ce qui signifie qu'elle existe deja à la compilation).
2/ soit de l'ajout de plugins de manière identique à ce que j'ai noté là haut : héritage d'une classe de base.
3/ soit de la génération de plugins (comme virtools ), ce qui revient au 2/.

Tout ce qui reste possible de purement dynamique serait - à ma connaissance - :
1/avoir des fonctions c référencées par leur nom /adresse ("afficheUnTruc" dans afficheUnTruc.dll) . Et les appeler. Mais dans ce cas, elles respectent une interface qui n'a rien à voir avec un quelconque superobject, et uniquement une interface d'appel en C.
2/ ou bien avoir un compilo en interne (gcc ou visual) pour modifier le code source initial, et lancer une recompil .

Bref :
-> il y a des aspects de conceptions néfastes -bad practices- qui sont de mon point de vue encourages par le superobject.
-> il n'y a pas de difficultés techniques à réaliser des programmes 'dynamiques' sans superobject.
-> la facilité de programmation avec un superobject peut s'avérer n'être qu'un leurre, apportant son lots de bugs potentiels, que le compilateur au minimum aurait interdits dans un cas "sans superobject".

Tout ceci n'est que mon point de vue .

[Matthieu Brucher]

Dans Qt, dans la VCL, tout ce qui appartient au framework (c'est à dire davantage que les seuls widgets) descend d'un même superobjet. Ce superobjet offre un certain nombre de services transversaux, typiquement, le RTTI (ou une alternative à celui ci), les communications interobjets et la gestion des évènements (via un système de messages)...

Ce n'est pas tout à fait vrai. Par exemple QVector n'est pas un QObject. Ne dérive de QObject que les classes qui en ont besoin !

[poukill]

J'ai suivi la discussion. Etant donné que ça a parlé beaucoup du mécanisme signaux/slots de Qt, je voulais ajouter ma pierre à l'édifice.
Je trouve que les signaux/slots de boost.Signals2 sont énormément mieux que ceux de Qt, c'est hallucinant. En combinaison avec Boost.Bind, on peut tout faire. On peut mettre dans le même paquet des signaux ayant des signatures différentes. Les signaux/slots de Qt sont assez rigides je trouve, et n'offrent pas beaucoup de possibilités au programmeur.
En parlant de signature: côté Qt, gaffe aux erreurs d'étourderies. Si on fait une faute de frappe dans un signal ou slot, paf... pas de problème ça compile quand même !!
Du coup, toutes les erreurs ne sont signalées... qu'à l'éxécution. Boost.Signals marque encore un point dans cette partie.

[yan]

Je trouve que les signaux/slots de boost.Signals2 sont énormément mieux que ceux de Qt, c'est hallucinant. En combinaison avec Boost.Bind, on peut tout faire. On peut mettre dans le même paquet des signaux ayant des signatures différentes.

Boost et Qt ne proposent pas le même de type signal /slot. De la à dire qu'il y en as un meilleur que l'autre, y as un gouffre...
Tu peut très bien utiliser boost dans Qt.

Les signaux/slots de Qt sont assez rigides je trouve, et n'offrent pas beaucoup de possibilités au programmeur.

Comme?

En parlant de signature: côté Qt, gaffe aux erreurs d'étourderies. Si on fait une faute de frappe dans un signal ou slot, paf... pas de problème ça compile quand même !!

C'est pour cela qu'ils sont dit "dynamique".

Du coup, toutes les erreurs ne sont signalées... qu'à l'éxécution. Boost.Signals marque encore un point dans cette partie.

Sans cela, les signal/slot de Qt ne seraient qu'une simple copie de ce de boost.
Ce de Qt sont plus avancés mais moins rapide que ce de boost. Avoir un fonctionne dynamique à un prix.

[poukill]

Hello Yan !

Comme?

Je pensais à plusieurs choses:
1- Le plus important selon moi : Boost.Signals2 permet de définir un orde d'appel très facilement:

Code :

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

1
2
3
4
5
 
boost::signals2::signal<void ()> sig;
 
  sig.connect(1, World());  // connect with group 1
  sig.connect(0, Hello());  // connect with group 0

2- Plus généralement, je trouve le mécanisme de boost.signals plus simple à appréhender. Que ce soit pour les valeurs de retour.

Just as slots can receive arguments, they can also return values

Ou bien le management des connections : chacun se connecte et se déconnecte quand il veut : pas besoin de passer par des macros SIGNAL, SLOT qui alourdissent le fonctionnenement.

Celà ne m'empêche pas d'utiliser Qt avec plaisir (après WxWidget, ça passe tout seul), mais n'empêche que.... j'ai vraiment eu un coup de coeur pour le design de boost.Signals... C'est super facile !
C'est rapide, flexible... Miam !

[yan]

Que ce soit pour les valeurs de retour.

je ne comprend pas ce que tu veut dire...
Un slot Qt est une fonction qui peut être appeler telle quel et retourner une valeur. La seule différence est quelle sera référencé dans les méta data par le moc.

Ou bien le management des connections : chacun se connecte et se déconnecte quand il veut

Tu peut le faire en Qt aussi

[Laurent Gomila]

C'est pour cela qu'ils sont dit "dynamique".

Sans cela, les signal/slot de Qt ne seraient qu'une simple copie de ce de boost.
Ce de Qt sont plus avancés mais moins rapide que ce de boost. Avoir un fonctionne dynamique à un prix.

En quoi les signaux/slots de Qt sont-ils plus dynamiques que ceux de boost ? Pour moi la seule différence est dans la philosophie et la technique d'implémentation : Qt a une approche historique à base de préprocessing et gère ses types de fonctions avec des chaines de caractères (d'où l'impossibilité de vérifier à la compilation), alors que boost peut se permettre une approche moderne à base de meta-programmation pour garder un typage fort. On ne lui en veut pas, ce genre de code de haut vol était tout bonnement impensable à l'époque où Qt a émergé.

Bref, si on veut comparer strictement les signaux/slots de Qt et ceux de boost, boost l'emporte haut la main. Ce qui fait l'intérêt du système de Qt, c'est qu'il est parfaitement intégré et intéragit avec les autres fonctionnalités de base du framework (meta-info, threads, ...). C'est un tout.

[Goten]

alors que boost peut se permettre une approche moderne à base de meta-programmation pour garder un typage fort.

IIRC l'émulation des variadiques templates est basé sur le prepocesseur (A grand coup de boost.pp). (ie c'est pas des typelists / mpl::vector)
Mais d'ailleurs ça reste de la MP. A base de PP certes mais c'est de la MP.

[yan]

En quoi les signaux/slots de Qt sont-ils plus dynamiques que ceux de boost ? Pour moi la seule différence est dans la philosophie et la technique d'implémentation : Qt a une approche historique à base de préprocessing et gère ses types de fonctions avec des chaines de caractères (d'où l'impossibilité de vérifier à la compilation), alors que boost peut se permettre une approche moderne à base de meta-programmation pour garder un typage fort.

Boost tout est fait à la compilation. C'est du code statique.
Qt se base sur les metadata et tout est fait pendant l'exécution. c'est du code dynamique.

Bref, si on veut comparer strictement les signaux/slots de Qt et ceux de boost, boost l'emporte haut la main. Ce qui fait l'intérêt du système de Qt, c'est qu'il est parfaitement intégré et intéragit avec les autres fonctionnalités de base du framework (meta-info, threads, ...). C'est un tout.

Tu trouve que c'est vraiment rien comme différence??
Qt as étendu le concept avec une approche dynamique ce qui lui permet d'être exploité dynamiquement, de proposer des fonctionnements en cas de multithreading, de pouvoir essayer de connecter deux objets sans forcement savoir ce qu'ils sont, ....

C'est ce qui permet l'auto-connexion.Tu charge dynamique un .ui tu appel une fonction et hop c'est connecté.
Tu peut connecté les objets par un script.
Tu peut exploiter l'eventloop dans les connections.
...

Et de base boost ne permet pas tous cela. Il ne fait que de l'appel directe avec des connexions validées à la compilation.

Ce que propose Qt et Boost ne sont pas identique, c'est tout. Je ne voie rien de choquant dedans.

Y as ce pdf qui exprime bien les différences (y as surement des petites choses à revoir)
http://www.elpauer.org/stuff/a_deepe..._and_slots.pdf
la conclusion que je trouve bonne

Signals and slots are a refinement of the Observer Pattern, a powerful
metaphor, and a great tool for assembling software from components.
They've been a part of the computer science landscape for over a
decade, and many mature implementations exist.
The implementation in Qt is a fundamental part of Qt's architechture,
and tightly integrated with its widgets, threading, introspection,
scripting, meta-object machinery, and visual GUI layout tool, Qt
Designer. Qt signals are member function signatures that can only be
emitted by the object of which they are members. Qt slots are specially
designated member functions. Qt widgets and connections can be
described in non-code resources and instantiated from such resources at
runtime. Qt signals and slots are built upon the introspection facility of
meta-objects in Qt, which is made possible by moc, the meta-object
compiler that produces meta-object classes matching user-defined
classes that specifically request this by mentioning Q_OBJECT in their
declaration.
Boost.Signals is a statically type-safe, template-based implementation of
signals and slots, where signals are instances of the template boost::signal
and slots are any callable signature. Boost.Signals stands alone, and
does not require introspection, meta-objects, or external tools; but the
downside of this is that Boost.Signals does not include a facility to
describe connections in non-code resources.
These two implementations both have great and complementary
strengths. Using them together until now has been a challenge. In Qt 4.1
and beyond, it's easy to use both if that happens to be right for your
project.
Any Qt-based project with a GUI will naturally use signals and slots. You
can also benefit from signals and slots in simulations and many
environments where software components can be assembled with loose
couplings into a larger system. As with any metaphor or technique,
moderation is the key. Choose wisely where to use signals and slots and
you will be rewarded with a system that's easier to understand, more
flexible, highly re-usable, and working sooner.

[Laurent Gomila]

Boost tout est fait à la compilation. C'est du code statique.
Qt se base sur les metadata et tout est fait pendant l'exécution. c'est du code dynamique.

Là tu me parles de comment c'est implémenté, mais au niveau de l'utilisateur que signifie ce "dynamisme" ?

Tu trouve que c'est vraiment rien comme différence??
Qt as étendu le concept avec une approche dynamique ce qui lui permet d'être exploité dynamiquement, de proposer des fonctionnements en cas de multithreading, de pouvoir essayer de connecter deux objets sans forcement savoir ce qu'ils sont, ....

C'est pour ça que j'ai précisé "si on veut comparer strictement les signaux/slots de Qt et ceux de boost", je ne parlais pas de la globalité du framework. Les meta-infos et l'aspect multithread sont orthogonaux aux signaux/slots, rien n'empêche de reconstruire les mêmes fonctionnalités que Qt par dessus les signaux/slots de boost.
Mais là il me semble qu'on retombe dans notre vieux débat du super-objet qui fait tout

[yan]

Là tu me parles de comment c'est implémenté, mais au niveau de l'utilisateur que signifie ce "dynamisme" ?

Concrètement :
1- qu'il peut se permettre une validation à l'exécution.
2- qu'il peut se permet qu'une connexion ne se créé pas sans pour autant empêcher l'exécution.
3- qu'il peut les manipuler de manière abstraite. Boost il faut connaitre la classe et la fonction.

Le tableau dans le pdf montre très bien la différence.

Tu peut y voir des points négatif comme positif.

C'est pour ça que j'ai précisé "si on veut comparer strictement les signaux/slots de Qt et ceux de boost", je ne parlais pas de la globalité du framework.

Pour moi on peut pas comparer strictement puisque que c'est différent.

Si tu veut voir concrètement les signal/slot de Qt comme ce de boost, oui boost gagne sur tout les plans.

Si tu veut voir concrètement les signal/slot de Boost comme ce de Qt, c'est impossible car boost ne propose pas la même choses.