IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

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


Sujet :

C++

  1. #1
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    [suite à cette discussion ]
    Salut,
    Beaucoup de framework, notamment IHM (Qt, wxWidgets, MFC) sont construits autour d'une super classe de laquelle héritent toutes ou parties des classes du framework. Que pensez-vous de cette pratique ? Est-ce une bonne chose dans l'architecture de vos logiciels ?
    Personnellement, je pense qu'il s'agit d'une pratique présentant plus d'inconvénients que d'avantages. Et vous ?

  2. #2
    Membre chevronné
    Avatar de poukill
    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 155
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 155
    Points : 2 107
    Points
    2 107
    Par défaut Que penser des frameworks et architectures qui font dériver toutes les classes d'un SuperObjet ?
    Citation Envoyé par 3DArchi Voir le message
    P.S. : quand on a un projet où tous les objets dérivent de ObjetBase, c'est mal barré d'un point de vue conception.
    Ah ? Mais si tu veux que toutes tes classes implémentent quelque chose comme GetTypeName().
    Perso j'ai une classe IObject dont 99 % des classes de mon projet dérivent. Au début ça m'a fait bizarre, mais c'est très pratique. Bonne combinaison avec ma factory et tout ce qui va avec...
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
     
    #ifndef OBJECT_H
    #define OBJECT_H
     
    #include <string>
     
    #include <boost/shared_ptr.hpp>
     
    #define DECLARE_TYPE(Class) \
    	virtual std::string GetTypeName() const {return #Class; }
     
    #define DECLARE_CLONE(Class) \
    	virtual boost::shared_ptr<IObject> Clone() const {return boost::shared_ptr<IObject>(new Class(*this)); }
     
     
     
    //-----------------------------------------------------------
    // IObject : Base class
    //-----------------------------------------------------------
     
    struct IObject
    {
    	IObject() {}
    	virtual ~IObject() {}
     
    	// Fonction to get the real type of the Class.
    	virtual std::string					GetTypeName	() const = 0;
     
    	// Polymorphic copy the object
    	virtual boost::shared_ptr<IObject>	Clone		() const
    	{
    		throw std::exception("This object is no clonable");
    	}
     
    };
     
    typedef boost::shared_ptr<IObject> object_ptr;
     
     
    #endif

  3. #3
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    Ce qui serait étrange, c'est que toutes tes classes dérivent directement de ton IObject
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    class MaClass : public IObject, (...)
    Par contre, qu'une classe dérive d'une classe qui dérive d'une classe qui dérive (...) qui dérive de IObject, ça ne pose pas de problème.

    Un exemple : dans Qt, la majorité des classes dérivent de QObject (pour pouvoir utiliser les meta infos, les signaux/slots, etc.)

  4. #4
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Citation Envoyé par poukill Voir le message
    Ah ? Mais si tu veux que toutes tes classes implémentent quelque chose comme GetTypeName().
    Citation Envoyé par gbdivers Voir le message
    Ce qui serait étrange, c'est que toutes tes classes dérivent directement de ton IObject
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    class MaClass : public IObject, (...)
    Par contre, qu'une classe dérive d'une classe qui dérive d'une classe qui dérive (...) qui dérive de IObject, ça ne pose pas de problème.

    Un exemple : dans Qt, la majorité des classes dérivent de QObject (pour pouvoir utiliser les meta infos, les signaux/slots, etc.)
    Beaucoup de framework ont des classes de ce genre : QObject (Qt)/wxObject (wxWidgets)/CObject (MFC). Mais, j'avoue que ça me laisse toujours dubitatif. Ca n'est pour moi pas très loin d'un void* d'un point de vue conception. Et comme tu le dis, la plus part du temps, ces objets n'ont qu'une ou deux fonctions de type info de classe ou clone. Elles ne peuvent avoir d'ailleurs pas vraiment d'autres fonctions car ils n'y a pas grand chose d'autre à factoriser. En plus tu obliges à de l'héritage et introduits des vtable là où il n'y en a peut être pas besoin.
    Je me demande si je ne préfèrerais pas passer alors par une classe trait pour définir et retrouver ces infos.

  5. #5
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 159
    Points
    3 159
    Par défaut
    Bonjour tous

    Citation Envoyé par 3DArchi Voir le message
    Salut,P.S. : quand on a un projet où tous les objets dérivent de ObjetBase, c'est mal barré d'un point de vue conception.
    Pas du tout. Comme le disent d'autres rédacteurs, c'est beaucoup utilisé dans de gros projets, car celà permet par exemple d'ajouter une gestion du cycle de vie des objets plus fine, de tracer leur existence en mode dev, etc...

  6. #6
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Citation Envoyé par jblecanard Voir le message
    Pas du tout. Comme le disent d'autres rédacteurs, c'est beaucoup utilisé dans de gros projets, car celà permet par exemple d'ajouter une gestion du cycle de vie des objets plus fine, de tracer leur existence en mode dev, etc...
    Que des fonctions qui n'ont rien à voir avec un héritage public...
    Je maintiens que faire dériver publiquement tous ses objets d'un MyGodObject est une erreur de conception ou, disons, une facilité de conception qui dans 99,9% des cas peut être abordée autrement.

  7. #7
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 159
    Points
    3 159
    Par défaut
    Citation Envoyé par 3DArchi Voir le message
    Que des fonctions qui n'ont rien à voir avec un héritage public...
    Pas exactement. Si tu veux gérer un compteur de référence par exemple, en appelant une méthode quand tu ajoute une référence et une autre pour la libérer, il faut que ton héritage soit public.

    Après, si ta conception est "plate" et que tous les objets héritent tous directement du même parent, là d'accord il y a quelque chose qui ne va pas. (edit clarté)

  8. #8
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    Un exemple de d'héritage public : dans Qt, faire dériver la majorité des objets de QObject permet de profiter les méta infos et des signaux/slots par exemple.
    une facilité de conception qui dans 99,9% des cas peut être abordée autrement
    Je suis d'accord qu'il s'agit d'une facilité et qu'il ne faut pas l'utiliser quand c'est pas nécessaire (et qu'il faut se poser la question, si on utilise ce type d'approche, de savoir s'il n'y a pas un problème de conception).

    Mais dans un framework (Qt, wx, MFC que tu citais), ce système permet quand même une grande souplesse et facilite son utilisation, ce qui n'est pas négligeable pour que le framework soit plus largement utilisé (les utilisateurs ne veulent pas forcement passer des semaines à lire la doc pour pouvoir utiliser le framework).

    Par exemple, pour les métas infos et les signaux/slots de Qt, comment aurais-tu fait à la place sans hériter d'un QObject arrière-arrière-arrière-...-arrière-grand-parent ?
    (ma question n'est pas totalement désintéressée je travaille actuellement sur une nouvelle version d'un framework pour le passer d'une version 1 qui utilise beaucoup les template mais qui est particulièrement complexe à utiliser, à une version 2 qui utilisera ce système. J'espère beaucoup gagner en facilité d'utilisation pour un cout en temps faible)

  9. #9
    Rédacteur
    Avatar de Laurent Gomila
    Profil pro
    Développeur informatique
    Inscrit en
    Avril 2003
    Messages
    10 651
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Avril 2003
    Messages : 10 651
    Points : 15 920
    Points
    15 920
    Par défaut
    Par exemple, pour les métas infos et les signaux/slots de Qt, comment aurais-tu fait à la place sans hériter d'un QObject arrière-arrière-arrière-...-arrière-grand-parent ?
    Pour les signaux/slots, boost.signal + boost.bind. Pas besoin d'une classe de base pour gérer ce genre de choses.
    Pour les meta-informations, il existe des bibliothèques qui implémentent une pseudo-reflexion sur les membres de manière presque pas intrusive. J'en ai moi-même écrit une il y a quelques temps. Sinon, on peut faire comme Qt et faire tourner un précompilateur pour extraire ces informations automatiquement ; là aussi il existe quelques projets open-source qui tournent pas mal.

    Le problème de Qt c'est qu'il a une base assez ancienne et que tout le reste repose dessus, ce serait carrément inenvisageable qu'ils se mettent à repenser leur système de QObject. Mais le fait est qu'avec du C++ moderne on peut faire mieux.

  10. #10
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Citation Envoyé par Laurent Gomila Voir le message
    Pour les signaux/slots, boost.signal + boost.bind. Pas besoin d'une classe de base pour gérer ce genre de choses.
    Pour les meta-informations, il existe des bibliothèques qui implémentent une pseudo-reflexion sur les membres de manière presque pas intrusive. J'en ai moi-même écrit une il y a quelques temps. Sinon, on peut faire comme Qt et faire tourner un précompilateur pour extraire ces informations automatiquement ; là aussi il existe quelques projets open-source qui tournent pas mal.

    Le problème de Qt c'est qu'il a une base assez ancienne et que tout le reste repose dessus, ce serait carrément inenvisageable qu'ils se mettent à repenser leur système de QObject. Mais le fait est qu'avec du C++ moderne on peut faire mieux.
    Plus les classes traits + dans certains cas la programmation orientée aspect peut aussi apporter des solutions + interface clonable si besoin uniquement pour les sémantiques d'entité (laisser la copie pour les sémantiques de valeur), +les infos de types dynamiques, etc.

    Citation Envoyé par gbdivers Voir le message
    les utilisateurs ne veulent pas forcement passer des semaines à lire la doc pour pouvoir utiliser le framework
    Vu que nous avons des forums pour chacun de ces frameworks et vus le nombre de questions qu'ils génèrent, je pense qu'au final si, on passe des semaines à lire de la doc

  11. #11
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    Pour les meta-informations, il existe des bibliothèques qui implémentent une pseudo-reflexion sur les membres de manière presque pas intrusive
    Plus les classes traits + dans certains cas la programmation orientée aspect peut aussi apporter des solutions + interface clonable si besoin uniquement pour les sémantiques d'entité (laisser la copie pour les sémantiques de valeur), +les infos de types dynamiques, etc.
    Moi pas tout comprendre mots à vous

    Plus sérieusement, je connais certaine de ces notions mais elle me semble quand même être d'un certain niveau.
    Effectivement, on peut se passer des super-objets pour faire la même chose (j'ai regardé un peu boost.signal que je connaissais pas... j'utilise jamais boost )
    Mais j'ai l'impression, en regardant les examples donnés dans la doc de boost.signal, qu'il s'agit au final de faire la même chose... en plus de lignes et en plus compliqué (mais c'est peut être parce que j'utilise Qt et non boost que j'ai cette impression, je suis plus habitué à la première manière).

    Au final, l'argument pour justifier les super-objets, ça reste la facilité de conception (pour un cout mémoire/temps non critique, surtout pour une ihm)
    Personnelement, j'ai opté pour une lib avec super-objets (wx avant, Qt maintenant) plutot que boost (par exemple) qui me semble beaucoup plus difficile à appréhender

    PS : avis d'un non-informaticien qui a appris en auto-didacte

  12. #12
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Points : 2 205
    Points
    2 205
    Par défaut
    Boost signal plus de ligne? Si ça peut m'éviter de devoir utiliser un compilateur dédié (systéme MOC de Qt) et des macros je préfère...

    Quand à la problématique de départ il suffit de voir les soucis qu'ont les javaistes avec equal()...

  13. #13
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Citation Envoyé par gbdivers Voir le message
    Moi pas tout comprendre mots à vous
    faq + tutoriels + google
    Citation Envoyé par gbdivers Voir le message
    Au final, l'argument pour justifier les super-objets, ça reste la facilité de conception (pour un cout mémoire/temps non critique, surtout pour une ihm)
    Personnelement, j'ai opté pour une lib avec super-objets (wx avant, Qt maintenant) plutot que boost (par exemple) qui me semble beaucoup plus difficile à appréhender
    Disons que les frameworks (Qt, wx, MFC) ont un historique qui amène à cet état de fait. Et comme le dit Laurent, ben maintenant, ça ne va pas changer.


    Citation Envoyé par gbdivers Voir le message
    PS : avis d'un non-informaticien qui a appris en auto-didacte
    Comme beaucoup de développeurs avant le diplôme ... ou pas.

  14. #14
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    Comme beaucoup de développeurs avant le diplôme ... ou pas.
    Je ne suis plus étudiant (et je n'ai pas étudié l'informatique)

    C'est peut être pour cela que j'ai un avis différent du votre : cela me gène pas d'utiliser des super-objets, des pré-compilateur (tant que c'est transparent) ou des macros.
    Par contre, ça me gène plus de devoir utiliser plusieurs libs différentes, d'augmenter le nombre de lignes de code ou de devoir utiliser des notions complexes.
    Mon objectif reste quand même d'obtenir le résultat voulu, même si c'est moins propre. En plus, c'est portable et plus facile à maintenir.
    Le framework sur lequel je travail actuellement (je viens de rejoindre l'équipe de dev) n'utilse pas par exemple les super-objets pour les méta-infos (classe home-made dédiée). Et je trouve ça très lourd à utiliser et à maintenir. Et j'espère (si j'arrive à convaincre l'équipe de dev) que l'on passera à un fonctionnement en super-objet (probablement QObject pour ne pas avoir à réécrire un équivalent).

    faq + tutoriels + google
    Pas d'inquiétude, je soigne mon manque de connaissance. progressivement

  15. #15
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 159
    Points
    3 159
    Par défaut
    Voilà qui est fort intéressant...

    Et quelle solution "moderne" utilisez vous si vous voulez standardiser la gestion du cycle de vie des objets dans votre projet ? Les smart pointers de boost ont l'air bien, quid on veut gérer l' add_ref/release à la main, suivre les compteurs, etc... ?

  16. #16
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    J'avoue ne pas très bien comprendre la question... (si c'est bien à moi que la question est posée)
    La gestion du cycle de vie des objets dépendent avant tout du logiciel et de sa conception. Un framework apporte (ou pas) des outils pour faciliter cette gestion. Donc on peut utiliser ce qu'on veut (pointeurs bêtes, pointeurs intelligent de boost ou de Qt, etc.)

    L'utilisation d'un framework (avec ou sans super-objets) n'interdit pas d'utiliser également d'autres libs en plus.

  17. #17
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 159
    Points
    3 159
    Par défaut
    Je pose la question à tout le monde en fait.

    Utiliser un super objet peut être une technique pour gérer le cycle de vie : le super objet va contenir un compteur de références, modifiable via des add_ref/release. Cela fournit une API identique de TTL sur tous les objets du projet. Pas besoin d'une table virtuelle supplémentaire (il n'y a pas de raisons que les objets enfants aient à écraser les addref/release existants), et la quantité de données supplémentaires n'est pas énorme (un int), sans rajouter pour autant une indirection supplémentaire lors des appels de méthodes.

    Bien sûr, on peut utiliser depuis le départ les smarts pointers de boost par exemple, mais on n'a pas la main sur les compteurs de référence. On pourrait imaginer un mécanisme ou les objets "s'enregistrent" auprès d'un conteneur qui peut les lister et faire d'autres opérations (ça peut être intéressant pour faire du profiling).

  18. #18
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    Par défaut
    Pas besoin d'héritage publique. Un héritage privé suffit alors. Je te l'accorde, ce n'est pas beaucoup mieux. Disons que c'est un peu moins pire.
    Typiquement, je préfère utiliser un pointeur intelligent à part (boost, qt ou autre).
    Et quitte à faire du profiling, je préfère alors instrumenter le pointeur intelligent et pas toutes les classes en leur imposant de dériver d'une super classe. En plus, pour du profiling - dont je n'aurais pas besoin à priori en prod -, peut être que d'autres approches peuvent se révéler plus intéressantes (par expl, la prog par aspect).
    Disons qu'il n'y a pas forcément THE solution au remplacement d'une super classe. Cela dépend du problème, de l'architecture du soft, du contexte du projet, etc. 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.

  19. #19
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 626
    Points : 30 684
    Points
    30 684
    Par défaut
    Salut,

    Je vois personnellement trois gros problèmes au recours d'un god_object...

    Le premier a déjà été évoqué consiste en la création d'une vtable qui pourrait ne pas s'avérer utile /nécessaire

    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

    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.

    Serais-je le seul à estimer qu'un tel rapport entre le nombre de fonctions utiles et le nombre de fonctions marginal a quelque chose d'aberrant

  20. #20
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Points : 2 205
    Points
    2 205
    Par défaut
    Citation Envoyé par jblecanard Voir le message
    Je pose la question à tout le monde en fait.

    Utiliser un super objet peut être une technique pour gérer le cycle de vie : le super objet va contenir un compteur de références, modifiable via des add_ref/release. Cela fournit une API identique de TTL sur tous les objets du projet. Pas besoin d'une table virtuelle supplémentaire (il n'y a pas de raisons que les objets enfants aient à écraser les addref/release existants), et la quantité de données supplémentaires n'est pas énorme (un int), sans rajouter pour autant une indirection supplémentaire lors des appels de méthodes.

    Bien sûr, on peut utiliser depuis le départ les smarts pointers de boost par exemple, mais on n'a pas la main sur les compteurs de référence. On pourrait imaginer un mécanisme ou les objets "s'enregistrent" auprès d'un conteneur qui peut les lister et faire d'autres opérations (ça peut être intéressant pour faire du profiling).
    boost::intrusive_ptr .. ?

    Mais comme le précise la doc de boost, c'est rare de vouloir avoir la main sur le compteur de références ... il vaut mieux avant prévoir un design à partir de shared_ptr..

    Pis si je dois tout dériver d'un seul objet juste pour du ref counting, un peu overhead pour moi...

Discussions similaires

  1. Réponses: 36
    Dernier message: 12/01/2011, 15h55
  2. Que penser des testeurs de Carte Mère
    Par Fabdeuche dans le forum Ordinateurs
    Réponses: 1
    Dernier message: 26/11/2010, 10h35
  3. Réponses: 0
    Dernier message: 15/11/2010, 11h51
  4. Un programme qui lance quelquechose toute les 50 minutes?
    Par altadeos dans le forum C++Builder
    Réponses: 4
    Dernier message: 12/03/2006, 11h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo