Destructeur doit-il être virtuel ou non ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour,

voilà le code:
Code:

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:

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 ;)

16/06/2014, 21h09
Trademark

:faq: 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.
17/06/2014, 09h51
Luc Hermitte

:/ Ce point de FAQ ne propose pas la solution du destructeur protégé et non virtuel.
17/06/2014, 11h47
Sergejack

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.
17/06/2014, 12h02
Luc Hermitte

Dans son cas. Un destructeur protégé et non virtuel suffit amplement.

~~@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:

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.

Citation:

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 :twisted:
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 ^^

Citation:

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:

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:

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:

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 :)

17/06/2014, 19h59
Ehonn

Citation:

Envoyé par Rafoudiablol

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

2) Si j'ai envie d'implémenter un smart pointeurs, j'ai le droit non :twisted:

Libre à toi de réinventer la roue carrée :p

Citation:

Envoyé par Rafoudiablol

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 ?
17/06/2014, 20h15
Rafoudiablol

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.
17/06/2014, 20h29
Ehonn

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

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).
18/06/2014, 10h48
ternel
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.
18/06/2014, 21h21
Rafoudiablol

Merci de me faire découvrir ce monde merveilleux. :traine:

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. :)
18/06/2014, 22h13
jblecanard

Citation:

Envoyé par Rafoudiablol

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 ;).

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 :D), 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:

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:

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:

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 :D) et que tu pars du principe que ta classe SDL_Reference EST-UNE Generic_Reference. Or, ce n'est pas vrai :aie:: ta SDL_Reference EST implémentée comme une Generic_Reference :D. 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 :aie:. 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:

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:

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:

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 ;)

19/06/2014, 09h37
the Hound

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 :) )

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:

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.

19/06/2014, 19h33
koala01

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 :aie:

Il y a donc une incompatibilité flagrante entre les besoins des fonctions virtuelles et des fonctions template :P. 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 :D

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 ;)
19/06/2014, 23h18
jblecanard
@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

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 :aie:)

Hum, mais ce n'est pas tout à fait vrai ça, ce code compile très bien en fichier objet :
Code:

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

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.

Citation:

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:

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.

23/06/2014, 17h39
oodini

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.

Voir 40 message(s) de cette discussion en une page