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 :

Destructeur doit-il être virtuel ou non ?


Sujet :

C++

  1. #1
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 11
    Points : 9
    Points
    9
    Par défaut Destructeur doit-il être virtuel ou non ?
    Bonjour,

    voilà le code:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    template<typename T>
    struct SmartPointerGeneric: public SmartPointer<GenericReference<T>, T>
    {};
    La classe SmartPointer ne définit aucune méthode virtuelle.
    Cela pose-t-il un problème si le destructeur de la classe SmartPointer n'est pas virtuel ?
    Dans ce cas, il n'y a aucune variable membre ajoutée dans la classe fille.

    Mais dans ce cas:
    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
     
    template<typename T> struct GenericReference
    {
           ~GenericReference()
           {
                  free();
           }
     
           virtual void free()
           {
                  delete _Ptr, _Ptr = 0;
           }
     
           int count;
           T *_Ptr;
    }
     
    struct SDL_Surface_Reference: public GenericReference<SDL_Surface>
    {
           virtual void free() override
           {
                  SDL_FreeSurface(_Ptr); _Ptr = 0;
           }
     
           HahaHihiHoho npk;
    }
    Est-ce une erreur de ne pas mettre le constructeur virtuel ?
    Et même si le constructeur n'est pas virtuel, est ce que le destructeur de npk (npk::~HahaHihiHoho()) sera appelé ?

    Merci

  2. #2
    Membre expérimenté Avatar de Trademark
    Profil pro
    Inscrit en
    Février 2009
    Messages
    762
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2009
    Messages : 762
    Points : 1 396
    Points
    1 396
    Par défaut
    ici.

    Dans tous les cas, il existe de bien meilleur technique pour faire des smart pointers sans héritage. Voir les pointeurs standards, notamment le shared_ptr pour le comptage de référence.

  3. #3
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    :/ Ce point de FAQ ne propose pas la solution du destructeur protégé et non virtuel.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  4. #4
    Membre éprouvé

    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 448
    Points : 1 234
    Points
    1 234
    Par défaut
    Fais tes destructeurs virtuels systématiquement.

    Ce faisant, tu n'encours aucun risque supplémentaire.
    Par contre, si tu ne le fais pas, tu vas avoir des soucis avec le polymorphisme.

    En conclusion et en me répétant, puisqu'il n'y a que des inconvénients à s'en passer : fais tes destructeurs virtuels systématiquement.


    Fais tes destructeurs virtuels quand la classe peut être héritées dans le cadre de polymorphisme.
    Sinon, ne les fais pas virtuels.

    Car polymorphisme + destructeurs non virtuels = problème.
    Mais destructeurs virtuels = utilisation d'espace mémoire supplémentaire , donc à éviter quand ils sont inutiles.
    Most Valued Pas mvp

  5. #5
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Dans son cas. Un destructeur protégé et non virtuel suffit amplement.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  6. #6
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2014
    Messages
    345
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : Juin 2014
    Messages : 345
    Points : 1 211
    Points
    1 211
    Par défaut
    @Sergejack Non.
    Un appel vers une fonction virtuelle est plus lent car passe par la v-table.
    Si la fonction peut ne pas être virtuelle, elle ne doit pas être virtuelle.

    Pour le destructeur, il y a, en gros trois cas :
    - la classe ne servira jamais de base à une autre classe : destructeur public non virtuel
    - la classe peut servir de base à une autre classe : destructeur public virtuel
    - la classe peut servir de base à autre classe, mais on ne peut détruire une instance que via cette dernière : destructeur protégé non virtuel.

    Je vais expliquer le dernier cas : au final, le "virtual" ne va servir que si on a une référence (dans le sens général) d'une classe pointant vers un objet d'une classe dérivée. Si on détruit l'objet, on veut que le destructeur de la classe dérivée soit appelé en plus de celui de la classe de base. Mais on pourrait aussi interdire la destruction de l'objet quand on le manipule en tant qu'instance de la classe de base. Exemple :

    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
    class Base {
      protected:
        ~Base() {}
    };
     
    class Derived : public Base {
      public:
        ~Derived() {} // Appelle Base::~Base() implicitement
    };
     
    void destroyBase(Base* b) {
      delete b; // Interdit, Base::~Base() est protégé
    }
     
    void destroyDerived(Derived* d) {
      delete d; // OK, Derived::~Derived() est public
    }
    On peut utiliser cette "technique" pour forcer l'utilisateur d'une classe à toujours prendre en charge la destruction de ses objets. Notez que le destructeur de la classe de base Base::~Base() est toujours appelé implicitement par les destructeurs des classes dérivées, donc il n'a pas besoin d'être virtuel.

  7. #7
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 11
    Points : 9
    Points
    9
    Par défaut
    Dans tous les cas, il existe de bien meilleur technique pour faire des smart pointers sans héritage. Voir les pointeurs standards, notamment le shared_ptr pour le comptage de référence.
    Euh... c'est un troll non ?
    1) L'héritage je l'utilise seulement pour définir des paramètres templates (puisque les typedef de template, ça n'existe pas)
    2) Si j'ai envie d'implémenter un smart pointeurs, j'ai le droit non
    3) Mon implémentation me convient très bien :p est elle permet de rajouter une couche aux types de la SDL qui on besoin d'être détruits par une fonction spécifique (SDL_FreeSurface, etc) afin d'éviter une redondance dans le code.
    4) C'est pas trop trop le sujet ^^

    la classe peut servir de base à autre classe, mais on ne peut détruire une instance que via cette dernière : destructeur protégé non virtuel.
    C'est exactement mon cas. Mais si l'on définit une nouvelle variable membre dans la classe dérivée, est-ce que le destructeur de cette variable sera appelé ?



    ------------------ EDIT --------------------
    J'ai finalement réussi à implémenter ce que je voulais.
    Voilà le code final de mon smart pointeur. J'espère qu'il ne bug pas.

    SmartPointer.hpp
    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
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    #ifndef SMART_POINTER_HPP
    #define SMART_POINTER_HPP
     
    #include <cassert>
     
    /**
     *  @brief ONLY USED IN SmartPointer
    **/
    template<typename T, typename PtrType = T>
    class SharedReference
    {
        public:
            SharedReference(PtrType* ptr):
                _Ptr(nullptr),
                _Count(1)
            {
                _Ptr = ptr;
            }
     
            /**
             *  @brief The destructor.
             *
             *  Bye default, use operator delete.
             *  To override this behavior, free _Ptr and reset it to NULL in the derived destructor.
            **/
            ~SharedReference()
            {
                assert(_Count == 0);
     
                if(_Ptr)
                {
                    delete _Ptr, _Ptr = nullptr;
                }
            }
     
        public:
            bool releaseOne()
            {
                _Count--;
     
                if(_Count == 0) {
                    return true;
                }
                else {
                    return false;
                }
            }
     
            void increaseOne()
            {
                _Count++;
            }
     
            PtrType* data() {
                return _Ptr;
            }
     
            const PtrType* c_data() {
                return _Ptr;
            }
     
        protected:
            PtrType* _Ptr;
     
        private:
            int _Count;
    };
     
    /**
     *  @brief Smart pointer.
     *
     *  The data is auto-freed after the destruction of this object.
    **/
    template<typename T>
    class SmartPointer
    {
        public:
            typedef T value_type;
     
     
        public:
            /**
             *  @brief The constructor.
             *
             *  @param[in] obj The object to be managed.
            **/
            explicit SmartPointer(value_type *ptr = nullptr);
     
            /**
             *  @brief The copy constructor.
             *
             *  The object is not copied.
            **/
            SmartPointer(const SmartPointer&);
            SmartPointer& operator=(const SmartPointer&);
            SmartPointer& operator=(value_type*);
     
            /**
             *  @brief The destructor.
             *
             *  Release this count.
            **/
            ~SmartPointer();
     
            /**
             *  @brief Release this count to the current reference.
             *
             *  If there are no count any more, the reference is freed.
            **/
            void release();
     
            /**
             * @brief Get if the object is not NULL.
            **/
            explicit operator bool() const;
     
            /**
             * @brief Get a pointer to the object.
             *
             *  Require that the object is not NULL.
            **/
            value_type& operator*() { return *ptr();}
            value_type* operator->() { return ptr();}
     
            const value_type& operator*() const { return *c_ptr();}
            const value_type* operator->() const { return c_ptr();}
     
            /**
             *  @brief Get the data.
             *
             *  The data must not be deleted.
             *  Require that the object is not NULL.
            **/
            value_type* ptr();
            const value_type* c_ptr() const;
     
        private:
            SharedReference<T> *_Ref;
     
            /**
             * @brief Add one count to the reference.
             *
             *  @return - The incremented Reference_t
             *          - Or NULL if there are no reference.
            **/
            SharedReference<T>* increase() const;
    };
     
    #include "SmartPointer.tpp"
     
    #endif // SMART_POINTER_HPP
    SmartPointer.tpp
    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
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
     
    #ifndef SMARTPOINTER_TPP
    #define SMARTPOINTER_TPP
     
    #include <cassert>
    #include "SmartPointer.hpp"
     
    #include "ns/io.hpp"
    using namespace io;
     
    template<typename T>
    SmartPointer<T>::SmartPointer(T *ptr):
        _Ref(nullptr)
    {
        if(ptr)
            _Ref = new SharedReference<T>(ptr);
    }
     
    template<typename T>
    SmartPointer<T>::SmartPointer(const SmartPointer &other):
        _Ref(nullptr)
    {
        *this = other;
    }
     
    template<typename T>
    SmartPointer<T>::~SmartPointer()
    {
        this->release();
    }
     
    template<typename T>
    SmartPointer<T>& SmartPointer<T>::operator=(const SmartPointer& other)
    {
        if(this != &other)
        {
            this->release();
            _Ref = other.increase();
        }
     
        return *this;
    }
     
    template<typename T>
    SmartPointer<T>& SmartPointer<T>::operator=(value_type* ptr)
    {
        this->release();
     
        if(ptr)
            _Ref = new SharedReference<T>(ptr);
     
        return *this;
    }
     
    template<typename T>
    SmartPointer<T>::operator bool() const
    {
        return _Ref && _Ref->data();
    }
     
    template<typename T>
    T* SmartPointer<T>::ptr()
    {
        assert(_Ref);
        return _Ref->data();
    }
     
    template<typename T>
    const T* SmartPointer<T>::c_ptr() const
    {
        assert(_Ref);
        return _Ref->c_data();
    }
     
    template<typename T>
    void SmartPointer<T>::release()
    {
        if(_Ref && _Ref->releaseOne())
        {
            delete _Ref;
        }
     
        _Ref = 0;
    }
     
    template<typename T>
    SharedReference<T>* SmartPointer<T>::increase() const
    {
        if(_Ref)
            _Ref->increaseOne();
     
        return _Ref;
    }
     
    #endif // SMARTPOINTER_TPP
    SDL_Smart.hpp
    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
     
    #ifndef SDL_SMART_HPP
    #define SDL_SMART_HPP
     
    #include <SDL2/SDL.h>
    #include "SmartPointer.hpp"
     
    template<>
    struct SharedReference<SDL_Surface>: public SharedReference<void, SDL_Surface>
    {
        SharedReference(SDL_Surface* ptr):
            SharedReference<void, SDL_Surface>(ptr)
        {
        }
     
        ~SharedReference()
        {
            SDL_FreeSurface(static_cast<SDL_Surface*>(_Ptr));
            _Ptr = nullptr;
        }
    };
     
    typedef SmartPointer<SDL_Surface>
        SMART_SDL_Surface;
     
    #endif // SDL_SMART_HPP

    Merci

  8. #8
    Membre chevronné Avatar de Ehonn
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2012
    Messages
    788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2012
    Messages : 788
    Points : 2 160
    Points
    2 160
    Par défaut
    Citation Envoyé par Rafoudiablol Voir le message
    1) L'héritage je l'utilise seulement pour définir des paramètres templates (puisque les typedef de template, ça n'existe pas)
    En C++11 si : Alias de templates grâce au mot-clé using (template typedef).

    Citation Envoyé par Rafoudiablol Voir le message
    2) Si j'ai envie d'implémenter un smart pointeurs, j'ai le droit non
    Libre à toi de réinventer la roue carrée :p

    Citation Envoyé par Rafoudiablol Voir le message
    3) Mon implémentation me convient très bien :p est elle permet de rajouter une couche aux types de la SDL qui on besoin d'être détruits par une fonction spécifique (SDL_FreeSurface, etc) afin d'éviter une redondance dans le code.
    Heu, si c'est tes smart pointer qui ont conscience que tel ou tel objet a besoin d'être libéré avec SDL_FreeSurface (?) tu as un problème de conception.

    Edit: J'ai vu que tu avais appelé des variables _Count, _Prt ou encore _Ref : Quels sont les identificateurs interdits par la norme ?

  9. #9
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 11
    Points : 9
    Points
    9
    Par défaut
    Regarde les sources si tu le souhaite, c'est juste en spécialisant la classe SharedReference que cela me permet d'avoir une routine de libération de mémoire en fonction du type. Par default, c'est l'opérateur delete qui est utilisé.
    Un smart pointer c'est pas bien compliqué, et je trouvais intéressant de l'implémenter moi-même, voilà tout. Et pour ce que je voulais exactement, il n'y à pas de type standard à ma connaissance

    Excusez-moi j'avoir utilisé des identificateurs interdits je ne sais pas quoi dire.

  10. #10
    Membre chevronné Avatar de Ehonn
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2012
    Messages
    788
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2012
    Messages : 788
    Points : 2 160
    Points
    2 160
    Par défaut
    Quand j'avais écrit, il n'y avait pas encore le code
    J'aurais fait plutôt l'inverse, fait un wrapper avec le bon destructeur. Cela permet de se passer des smart pointers la plupart des cas.

    Citation Envoyé par Rafoudiablol Voir le message
    Et pour ce que je voulais exactement, il n'y à pas de type standard à ma connaissance
    En C++11, si std::unique_ptr et std::shared_ptr (et éventuellement std::reference_wrapper).

  11. #11
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 189
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 189
    Points : 17 141
    Points
    17 141
    Par défaut
    Rafoudiablol, je t'invite à découvrir le monde merveilleux du C++11, avec des choses magiques comme:
    • les unique_ptr et shared_ptr,
    • les using généralisés,
    • les unsorted set et map, (tables de hashage)
    • les listes d'initialisations,
    • les expressions régulières,
    • du threading,


    regarde entre autre cppreference.com. C'est une référence du langage, mais tu y découvriras beaucoup de choses.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  12. #12
    Futur Membre du Club
    Homme Profil pro
    Inscrit en
    Mai 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Mai 2012
    Messages : 11
    Points : 9
    Points
    9
    Par défaut
    Merci de me faire découvrir ce monde merveilleux.

    Ce que je veux faire est en effet possible avec des shared_ptr: le deuxième argument du constructeur est un pointeur sur la fonction de déallocation désirée.
    Cependant, c'est tellement plus beau d'écrire SharedPtr<SDL_Surface> myptr(0) que shared_ptr<SDL_Surface> myptr(0, SDL_FreeSurface). Et cela évite de stocker le pointeur de la routine de déallocation puisque tout est géré par les templates à la compilation.

  13. #13
    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 156
    Points
    3 156
    Par défaut
    Citation Envoyé par Rafoudiablol Voir le message
    Cependant, c'est tellement plus beau d'écrire SharedPtr<SDL_Surface> myptr(0) que shared_ptr<SDL_Surface> myptr(0, SDL_FreeSurface). Et cela évite de stocker le pointeur de la routine de déallocation puisque tout est géré par les templates à la compilation.
    Pour la facilité d'écriture, pas d'excuse, tu peux te faire un template qui alias make_shared avec les traits qui vont bien pour sélectionner le deleter.
    Pour le stockage c'est vrai, mais bon, un pointeur dans le bloc de contrôle en plus, c'est franchement pas ça qui va pourrir ta mémoire .
    Find me on github

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

    Informations professionnelles :
    Activité : aucun

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

    Je ne vais pas me lancer dans les grandes explications conceptuelles pour justifier mon point de vue de peur de digresser trop lourdement (je ne le ferai que si l'on me le demande ), mais, en deux mots, le destructeur d'une classe template ne devrait jamais être virtuel.

    Pour tenter une explication minimale, disons qu'il y a deux situations possibles:
    Soit, la classe template est spécifiquement développée pour intervenir comme classe de base dans une hiérarchie de classe, mais elle agit selon le concept d'interface, son destructeur est protégé et non virtuel, soit son destructeur est public et non virtuel, et la classe ne peut en aucun cas servir de classe de base dans une relation d'héritage public.

    Dans le premier cas, tu interdis (du fait du destructeur protégé) l'utilisation de la classe elle-même:
    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
    template <typename T>
    class Interface{
        public:
            /* ... */
        protected:
            ~Interface(){}
    };
    class MaClasse : public Interface<MaClasse>{
        /* ... */
    };
    int main()
        Interface<int> erreurInt; // erreur : ~Interface<int> protégé dans ce contexte
        Interface<MaClasse> erreurMaClasse; // erreur : ~Interface<MaClasse> protégé dans ce contexte
        MaClasse mc; // ok : ~MaClasse peut accéder à ~Interface<MaClasse> ;-)
    }
    Dans le deuxième cas, tu ne peux pas utiliser la classe template comme classe de base dans une relation d'héritage public:
    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
    template <typename T>
    class TClass{
        public:
            /* ... */
            ~TClass(){}
    };
    // on ne devrait jamais faire ceci
    class MaCasse : public TClass<MaClasse>{
        /* ... */
    };
    class Autre : public MaClasse{
        /* ... */
    };
    int main(){
        // Car, si on fait:
        TClass<MaClasse> * temp = new Autre; // héritage public --> on peut avoir un pointeur sur la classe de base 
                                           // pointant sur une instance d'une classe dérivée
        /* ... */
        delete  temp; // ouppss... ~TClass<MaClasse> est appelé, mais pas ~MaClasse ni ~Autre
        return 0;
    }
    Par contre, rien n'interdit d'envisager l'héritage privé, qui représente une relation "est implémenté en termes de" :
    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
    template <typename T>
    class TClass{
        public:
            /* ...*/
            ~TClass(){}
    };
    class MaClasse :private TClass<MaClasse>{
     
    };
    int main{
         TClass<int> okInt; // OK : ~TClass<int> est public
         TClass<MaClasse> okMaClasse; // OK ~TClass<MaClasse> est public
         MaClasse mc; // OK
         TClass<MaClasse> * ptr = new MaClasse; //erreur : TClass<MaClasse> n'est pas une base directe de MaClasse
         /* ... */
         return 0;
    }
    Ton erreur de conception vient en réalité du fait que l'on explique souvent l'héritage public comme étant une relation EST-UN (ce qui n'est pas faux ) et que tu pars du principe que ta classe SDL_Reference EST-UNE Generic_Reference. Or, ce n'est pas vrai : ta SDL_Reference EST implémentée comme une Generic_Reference . Tu subis de plein fouet la même confusion de genre que celle qui pousse les gens à décider que Carre hérite de Rectangle ou que ListeTriee hérite de Liste.

    Le problème, c'est que cette définition de l'héritage public ne rend aucun compte des impératifs qui y sont liés . Mais ca, j'en parlerai (peut etre) plus tard .

    Enfin bref, tu as deux solutions :

    Soit tu envisage un héritage privé de SDL_Reference avec Generic_Reference, soit tu envisages le fait que Generi_reference puisse utiliser un foncteur, ce qui lui ferait prendre la forme de
    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
    template <typename T, typename destructor = void>
    class Generic_Reference{
        /* ... */
    };
    /* Par défaut, on utilise la fonction delete */
    template <typename T>
    Generic_Reference<T, void>::~Generic_Reference(){
        /* tout ce qui permet de s'assurer qu'il faut bien libérer la mémoire */
        delete ptr_;
    }
    /* on peut envisager d'utiliser un pointeur de fonction */
    template <typename T>
    Generic_reference<T, void (Func*)(T*)>::~Generic_reference(){
        /* tout ce qui permet de s'assurer qu'il faut bien libérer la mémoire */
        Func(ptr_;)
    }
    /* mais l'idéal est sans doute plutot l'utilisation d'un foncteur */
    template <typename T, typename deleter>
    Generic_reference<T, deleter>::~Generic_reference{
        /* tout ce qui permet de s'assurer qu'il faut bien libérer la mémoire */
        deleter<T>()(ptr_);
    }
    La dernière surcharge sera prévue pour être utilisée avec un foncteur ressemblant à quelque chose comme
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    template <T>
    struct SDL_deleter{
        void operator()(T* ptr) const{
             SDL_freeSurface(ptr);
        }
    };
    Ceci te permettra d'avoir un code ressemblant à
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    int main(){
        Generic_Reference<SomeType, SDL_deleter> myData(new SomeType(/*parametres*/);
        /* .. */
        return 0;
    }
    Notes d'ailleurs que c'est, peu ou prou, le principe suivi par les pointeurs intelligents apparus en C++11
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  15. #15
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2014
    Messages
    345
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : Juin 2014
    Messages : 345
    Points : 1 211
    Points
    1 211
    Par défaut
    C'est intéressant cette histoire de destructeur non virtuel de classe template, tu as des liens à fournir explicitant un peu tout ça ? (je suis curieux )

  16. #16
    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 156
    Points
    3 156
    Par défaut
    Je ne suis pas entièrement d'accord avec Koala1 pour le coup. Rien de ce qu'il dit n'est faux en soit, mais part du principe que le propriétaire de l'objet ne devrait jamais le référencer par un pointeur (intelligent ou non) vers son interface quand celle-ci est une classe template. C'est plutôt fort comme contrainte, et qu'apporte-t-elle comme bénéfice ? On pourrait très bien avoir ce cas de figure :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    struct Euro {};
    struct Dollar {};
     
    template <typename Money> class ProduitFinancier {};
    class BourseParis : public ProduitFinancier<Euro> {};
     
    int main()
    {
      ProduitFinancier<Euro> * p = new BourseParis;
      delete p;
      return 0;
    }
    Dans lequel cas, il vaut mieux avoir un destructeur virtuel sur ProduitFinancier. Pour le cas particulier du CRTP, pris pour exemple par Koala1 d'ailleurs, je suis d'accord que ça ne se fait pas.
    Find me on github

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

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 614
    Points : 30 626
    Points
    30 626
    Par défaut
    A vrai dire, je n'ai pas vraiment de lien sur le sujet, mais il y a une certaine logique à cela:

    Lorsque l'on y regarde du point de vue purement conceptuel, une fonction virtuelle permet de disposer du polymorphisme d'inclusion (celui auquel on pense en premier par abus de langage d'un point de vue orienté objet lorsque l'on parle de "polymorphisme" sans plus de précision).

    C'est parce que tu déclare la fonction "draw" comme virtuelle dans une classe "form" que l'appel à ptr->draw provoquera le tracé d'un cercle si ptr pointe sur un objet de type circle et celui d'un triangle si ptr pointe sur un objet de type triangle (circle et triangle héritant publiquement de form).

    Le fait est que les classes template sont l'expression du paradigme dit générique, et non du paradigme orienté objet. Le paradigme générique permet de profiter du polymorphisme dit "paramétrique" : le simple fait de changer le type du paramètre template suffit à provoquer l'adaptation du comportement de la classe. Et cette adaptation se fait lors de la compilation!

    On n'a donc aucun besoin de permettre à l'instanciation d'une classe template d'adapter le comportement de ses fonctions lors de l'exécution, pour la simple et bonne raison que le comportement est déjà adapté lors de la compilation

    De plus, une fonction virtuelle ne sera jamais inlinée, à cause du passage par la vtbl. Or, toutes les fonctions template (ou fonction membres de classes template) sont, par nature inline, vu que le compilateur a besoin du code de leur implémentation afin de pouvoir générer le code binaire adapté au type des données

    Il y a donc une incompatibilité flagrante entre les besoins des fonctions virtuelles et des fonctions template . La seule exception étant le cas où une classe template hérite publiquement d'une classe non template: à ce moment là, il est possible de redéfinir le comportement d'une fonction (virtuelle) de la classe de base dans la classe template, malgré la certitude que l'inlining ne sera pas respecté.

    @jblecanard >> Le problème est que tu présente un code beaucoup trop fragmentaire que pour me permettre de me faire une idée précise sur le sujet et que je ne connais absolument rien en produits financiers

    Mais, a priori, j'aurais tendance à penser soit qu'il "manque quelque chose" entre BourseParis et ProduitFinancier, soit que tu ne respecte pas vraiment le LSP en décidant d'utiliser l'héritage public, tout comme LSP est violé lorsque l'on décide de faire hériter Carré de Rectangle ou ListeTriee de Liste
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  18. #18
    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 156
    Points
    3 156
    Par défaut
    @Koala1

    Je suis globalement d'accord, mais je vais encore pousser un peu le débat. J'adopte une approche pragmatique : pour moi, un template une fois instancié n'a aucune différence avec une version implémentée à la main. Le polymorphisme paramétrique est un outil puissant qui permet d'écrire moins de code. Mais une fois instanciée, une classe template a toutes les propriétés d'une classe normale. Du coup, une fois que j'ai instancié ma classe template, je ne vois pas pourquoi je me priverais du paradigme orienté objet potentiel qu'elle offre (ceci ne se limitant pas à la surcharge d'une fonction membre virtuelle).

    Citation Envoyé par koala01 Voir le message
    Or, toutes les fonctions template (ou fonction membres de classes template) sont, par nature inline, vu que le compilateur a besoin du code de leur implémentation afin de pouvoir générer le code binaire adapté au type des données )
    Hum, mais ce n'est pas tout à fait vrai ça, ce code compile très bien en fichier objet :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    template <typename T> int f(T const&);
    extern template int f<double>(double const&);
    int g() { return f(1.); }
    Les problèmes se produiront à l'édition de lien si on ne fournit pas le symbole. Ce cas de figure se rencontre souvent avec l'introduction de extern dans C++11. On perd l'inlining oui (et encore, les futurs linkers permettront d'inliner à l'édition de lien, j'ai hâte !).

    Citation Envoyé par koala01 Voir le message
    Mais, a priori, j'aurais tendance à penser soit qu'il "manque quelque chose" entre BourseParis et ProduitFinancier, soit que tu ne respecte pas vraiment le LSP [...]
    C'est bien le problème, tu as tendance à penser, mais tu ne peux pas être sûr, à juste titre : le respect du LSP se mesure au regard de la sémantique métier des objets implémentés. En l'absence de ces informations, le fait d'hériter publiquement d'une classe template n'en fait pas en soit un use case invalide.

    Maintenant, je vais quand même conclure en donnant le même conseil que toi, car malgré mon discours, dans la pratique, je n'ai jamais rencontré le besoin d'hériter publiquement d'une classe template autrement que par CRTP. Si je le rencontre dans un code, je m'en méfierais. C'est juste que je ne vois pas de raison théorique de l'interdire.
    Find me on github

  19. #19
    Membre émérite
    Avatar de white_tentacle
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2008
    Messages : 1 505
    Points : 2 799
    Points
    2 799
    Par défaut
    Maintenant, je vais quand même conclure en donnant le même conseil que toi, car malgré mon discours, dans la pratique, je n'ai jamais rencontré le besoin d'hériter publiquement d'une classe template autrement que par CRTP. Si je le rencontre dans un code, je m'en méfierais. C'est juste que je ne vois pas de raison théorique de l'interdire.

    Version courte : faites comme Koala1 a dit.
    Sauf si vous avez besoin de faire autrement, ce qui a été mon cas.

    Pour faire court (la version longue est trop longue à détailler ici), j’ai eu besoin de faire ça :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    template<typename A>
    class Base {
    ...
    }; // fournit des services avec A
     
    template<typename A, typename B>
    class Derived : public Base<A> {
    ...
    } // est-un Base<A> au sens LSP, a un comportement spécialisé par rapport à à Base<A>, etc. Mais dépend de B.
    Un détail important toutefois, qui rejoint en grande partie ce que Koala disait : Base<A> est abstraite. Je crois qu’il a simplement omis qu’une interface / classe abstraite peut très bien être template dans certains contextes, et qu’on peut vouloir mixer un polymorphisme statique et un polymorphisme dynamique.

  20. #20
    Membre émérite
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    2 764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 2 764
    Points : 2 705
    Points
    2 705
    Par défaut
    Il m'arrive quelquefois de mélanger polymorphisme statique et dynamique, quand une part de variabilité peut être connue à la compilation, et une autre part seulement à l'exécution.

Discussions similaires

  1. Réponses: 2
    Dernier message: 09/09/2010, 13h13
  2. Réponses: 0
    Dernier message: 11/01/2010, 15h54
  3. Réponses: 5
    Dernier message: 24/10/2007, 16h45
  4. Réponses: 6
    Dernier message: 01/10/2007, 23h23

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