Quelques questions sur Modern C++ Design

Bonjour à tous, j'ai entamé le premier chapitre de Modern C++ Design et j'ai quelques questions :

-Pourquoi hérité publiquement de certaines classes de politique ?
Un exemple du livre :

Code:

---

1 2	template<class T, template <class>class CheckingPolicy> class SmartPtr : public CheckingPolicy<T>;

---

-Les template<template<class>class Truc> ne sont-ils pas dangereux :
Par exemple, template<template<class> class Allocator> ne peut-il pas poser problème :
Comment sait-on que Allocator n'a qu'un seul template ?
Ne faudrait-il pas faire plutôt quelque chose comme (si cela est autoriser par c++0x, j'ai un doute)

template<class T, template<typename ...Args> class Allocator, typename ...AllocatorTemplates>

Ensuite, on ferait un static_assert(sizeof...(AllocatorTemplates)+1==sizeof...(Args));

-Dernière question : je n'ai pas du tout compris le "sizeof trick" pour voir si A peut être convertit explicitement en B.

Merci de m'éclairer.

Citation:

---

Envoyé par NoIdea

Bonjour à tous, j'ai entamé le premier chapitre de Modern C++ Design et j'ai quelques questions :

-Pourquoi hérité publiquement de certaines classes de politique ?

---

Pourquoi pas? (ie qu'est ce qui te gêne?).

Citation:

---

-Les template<template<class>class Truc> ne sont-ils pas dangereux :
Par exemple, template<template<class> class Allocator> ne peut-il pas poser problème :
Comment sait-on que Allocator n'a qu'un seul template ?
Ne faudrait-il pas faire plutôt quelque chose comme (si cela est autoriser par c++0x, j'ai un doute)

---

Le livre vise la norme 03. (et je sais pas si une telle syntaxe est autorisée). Et sinon ça pose rarement des problèmes en pratique car on sait ce exactement quelle genre de classe template va être passer en paramètre template et donc le nombre de paramètres templates attendus. (comme ici avec un allocateur, le type de l'objet à allouer.)

Citation:

---

-Dernière question : je n'ai pas du tout compris le "sizeof trick" pour voir si A peut être convertit explicitement en B.

Merci de m'éclairer.

---

Va falloir être plus précis sur ce que tu comprends pas!

Il utilise le fait que l'opérateur elipse est le dernier choix fait par le compilateur lors de la résolution de la fonction. Donc si une conversion existe elle est préférée. (donc de T vers U)

Citation:

---

Il utilise le fait que l'opérateur elipse est le dernier choix fait par le compilateur lors de la résolution de la fonction. Donc si une conversion existe elle est préférée. (donc de T vers U)

---

C'est cette information qui me manquait.

Citation:

---

Et sinon ça pose rarement des problèmes en pratique car on sait ce exactement quelle genre de classe template va être passer en paramètre template et donc le nombre de paramètres templates attendus. (comme ici avec un allocateur, le type de l'objet à allouer.)

---

C'est la cas pour un allocateur, mais pour un conteneur ?
Supposons ceci (je ne dis pas que ce code est utile) :

template<class T, template<class>Conteneur>
class Matrix;

Il faudrait 2 classes pour la STL (il y a l'allocateur en plus) et peut être N pour d'autres... Sachant qu'on ne va pas forcément utiliser Conteneur<T>, donc l'utilisateur ne peut pas être au courant de quoi passer.

La raison pour laquelle ce n'est pas forcément un conteneur<T> est simple :
Imaginons un système d'indexation pour rendre cela plus rapide, on utilisera peut être une paire <T,Index>, ce dont l'utilisateur n'a aucune connaissance.

Citation:

---

Pourquoi pas? (ie qu'est ce qui te gêne?).

---

J'ai toujours eut comme principe : utiliser l'héritage uniquement lorsqu'il est justifié. Or, la il me parait inutile.

Pour l'héritage, il n'est pas inutile. Imaginons qu'un policy en particulier ait besoin d'une fonction supplémentaire pour faire son boulot. Grâce à cet héritage public, un objet qui utilisera cette politique se retrouvera avec cette fonction dans son interface publique.

L'objectif des classes de politiques c'est de découper l'interfaces en plusieurs classes, chaques parties de ce découpage étant indépendante les unes des autres, et ensuite de les regrouper, et pour les regrouper tu n'as pas le choix d'utiliser l'héritage publique.

Citation:

---

(page 7) A policy defines a class interface or a class template interface.

---

Ton exemple ne va pas, un conteneur ne définie pas une classe de politique, pas naturellement en tout cas. Un allocateur par contre oui. Les classes de politique servent à définir des comportements, un conteneur ne définie pas (naturellement) un comportement d'une partie d'une classe.

Citation:

---

Envoyé par Flob90

Ton exemple ne va pas, un conteneur ne définie pas une classe de politique, pas naturellement en tout cas.

---

Pour toi, on ne peut pas voir une classe comme std::stack ou std::queue comme un classe définie par politique ?

Citation:

---

Envoyé par NoIdea

C'est cette information qui me manquait.

---

Il me semble qu'il le dit dans le bouquin mais ça se peut que je confonde!.

Citation:

---

C'est la cas pour un allocateur, mais pour un conteneur ?
Supposons ceci (je ne dis pas que ce code est utile) :

template<class T, template<class>Conteneur>
class Matrix;

---

De toute façon c'est faux ceci. Il faut que ça match complétement les paramètres template du type attendu, paramètre par défaut compris!. Donc dans le cas d'un conteneur deux paramètres template dont un avec un type par défaut. (l'allocateur sur le type).

Citation:

---

J'ai toujours eut comme principe : utiliser l'héritage uniquement lorsqu'il est justifié. Or, la il me parait inutile.

---

C'est un très bon principe. Mais ici il ne s'applique pas :). (cf la réponse de Loic).

J'ai peut être mal compris le principe, mais il me semblais qu' une classe de politique ne servais qu'en interne de la classe : un allocateur ne necessite pas a l'utilisateur d'y acceder.

Un conteneur peut être une politique : façon de stocker les données.
Justement Goten,
Tout le problème est que chaque conteneur a pas le même nombre de template (ceux de la stl oui, mais si je veux mettre un qlist )

Ca l'est mais que partiellement, si tu regardes comment sont faites las classes que tu cites, tu verras qu'ils ont bien découpés avec une classe du genre PolicyStorage, mais que pour la partie allocateurs, il n'ont pas pu rendre indépendant les 2 parties (on ne peut pas de toute facon, l'allocateur intervient dans le conteneur). Et la solution qu'ils ont choisi est de laisser tomber l'allocateur à ce niveau et de laisser totalement la responsabilité de l'allocateur au constructeur, au final ca marche, mais là où tu ferais

Code:

---

1 2	std::vector<MonType, MonAllocateur<MonType> > v;

---

Tu devras faire

Code:

---

1 2	std::queue<MonType> q(MonAllocateur<MonType>());

---

Du coup pour un conteneur classique, l'allocateur définie réelement le comportement de la classe (elle fait partie intégrante de celle ci, tu le connais juste avec le type), pour les adaptateur de conteneur ce n'est pas le cas.

D'autre part, il y a quand même des restrictions, ce n'est pas n'importe quel conteneur qui peut servir, donc le problème de l'OP ne se pose pas, pour servir de classe de politque dans ce cas, Container<T> doit être valide, il n'y a pas de problème de nombre de paramètre template valide, ni d'allocateur.

Et enfin, c'est pas du tout l'esprit des classes de politique présentées ensuite dans MC++D, dans toute la suite ce sont des classes de politique template, pour les adaptateurs de conteneurs, ce sont des classes de politiques simple (et si tu regardes bien l'interface, tu vas même te rendre comptes que le paramètre T ne sert à, presque, rien si ce n'est définir la valeur par défaut du paramètre Container, alors que dans MC++D, le T sert tout le temps).

(J'ai bien dit "naturellement", en mettant des restrictions comme le fait le comité ca le devient dans la limite des ces restrictions)

Et par rapport à mon message précédent, j'exagère un peu quand je dis qu'il n'y a pas le choix de l'héritage publique, je pense que Andrei présente tout ces exemples comme ca pour bien montrer qu'il y a eu un découpage de l'interface, mais tu pourrais les mettre en attributs aussi dans certains cas (c'est le cas pour les adaptateurs de conteneurs) et Andrei le dit :

Citation:

---

(page 9) Such a class will either contain or inherit one of the three classes defined previously,

---

Citation:

---

Envoyé par NoIdea

J'ai peut être mal compris le principe, mais il me semblais qu' une classe de politique ne servais qu'en interne de la classe : un allocateur ne necessite pas a l'utilisateur d'y acceder.

---

Imagine que l'allocateur alloue dans une zone de mémoire partagée nommée. Il va bien falloir que l'utilisateur puisse fournir le nom de cette zone. Ou encore pour une allocation par pool, peut-être l'utilisateur est-il dans certains cas intéressé par connaître le taux de remplissage du pool.

Il est donc intéressant que la politique puisse enrichir l'interface de la classe.

Merci Loic de m'avoir éclairé sur ce point.

Citation:

---

D'autre part, il y a quand même des restrictions, ce n'est pas n'importe quel conteneur qui peut servir, donc le problème de l'OP ne se pose pas, pour servir de classe de politque dans ce cas, Container<T> doit être valide, il n'y a pas de problème de nombre de paramètre template valide, ni d'allocateur.

---

C'est juste plus facile si on peut mettre tout type de conteneur...

Si tu reprends le livre tu vas voir qu'il y a une progression dans la reflexion, la première idée c'est ca :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Widget { Data d; Data1 d1; Data2 d2; public: void foo1(); void foo2()   void bar1(); void bar2();   void goo() { foo1(); bar2(); } };

---

Et là Andrei nous dit (et ca semble vraie), qu'il arrive souvent que les comportement des groupe d1 foo1 foo2 et d2 bar1 bar2 soit totalement indépendant. Et il nous propose dans ce cas de faire quelque chose comme :

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

template<class FooPolicy, class BarPolicy> class Widget : public FooPolicy, public BarPolicy { Data d; public: void goo() { foo1(); bar2() } };   struct Policy1 { void foo1(); void foo2(); protected: ~Policy1(){} private: Data1 d1; };   struct Policy2 { void bar1(); void bar2(); protected: ~Policy2(){} private: Data2 d2; };   //Utilisation Widget<Policy1, Policy2> w;

---

A ce niveau là il a introduit un point de variation : il peut changer le comportement des ces classes sans tout refaire.
Ensuite, il rend son code plus générique, là ca marche avec le type Data, mais ca pourrait être un type quelconque, non ? (On suppose que Data1 et Data2 se déduise de Data). Il passe donc à des templates :

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

template<class T, class FooPolicy, class BarPolicy> class Widget : public FooPolicy, public BarPolicy { T d; public: void goo() { foo1(); bar2() } };   template<class T> struct Policy1 { void foo1(); void foo2(); protected: ~Policy1(){} private: Data1_Trait<T>::type d1; //Le trait j'ai juste pour pas oublier que le paramètre T est bien utile, tu verras dans MC++D que ce sera souvent des choses comme T* ou T& ou autre };   //Similaire   //Utilisation Widget<Data, Policy1<Data>, Policy2<Data> > w;

---

Et là il a l'idée (c'est la force des classes de politique AMHA), de supprimer la répétition du T grace à un outils syntaxique du langage, les TTP :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

template<class T, template<class>class FooPolicy, template<class>class BarPolicy> //TTP class Widget : public FooPolicy<T>, public BarPolicy<T> { T d; public: void goo() { foo1(); bar2() } };   //Comme avant   //Utilisation Widget<Data, Policy1, Policy2> w; //Plus de T !

---

Rien ne t'empche de concecoir un classes qui fonctionne avec des classes de politque plus exotique, du genre :

Code:

---

1 2	template<class U, class V, template<class> class P1, template<class, class>P2> class A : public P1<U>, public P2<U,V>;

---

Et pour un nombre de paramètre variable, si tu fais (en C++1x) :

Code:

---

1 2 3

template<class T, template<class...> class P, class... Arg> class A : public P<T, Arg...> {};

---

Ca doit marcher, mais ca impose une limitation, tu ne peux plus mettre de classes de politiques par defaut (cf plus loin dans MC++D).

Dans ce code les Arg... pourrait être qualifié de additionnel : c'est un groupe de paramètre qui sera passé à tout les classes de politique qui peuvent recevoir un nombre variables de parmaètre template. Ca impose aussi une condition sur les classes de politiques à nombre de paramètre variables : elles doivent tous recevoir le même groupe de paramètres.

Cependant, lorsque Andrei introduit le paramètre T, il le fait car ce T intervient dans sa classe final, il le fait pour obtenir plus de généricité, si l'introduction de Arg... est nécessaire à la classe alors oui ca peut-etre utile, sinon pas vraiment.

Je m'explique, dans ton exemple tu nous propose quelque chose comme ca :

Code:

---

1 2 3

template<class T, template<class>class StoragePolicy> class Matrix : public StoragePolicy<T> {};

---

Pour mieux voir les choses on va introduire une seconde classes de politique, disons OwnershipPolicy (qui détermine comment la matrice doit gérer la durée de vie des objets)

Code:

---

1 2 3

template<class T, template<class>class StoragePolicy, template<class>class OwnershipPolicy> class Matrix : public StoragePolicy<T>, public OwnershipPolicy<T> {};

---

Avec l'introduction de cette second classe on voit bien que les autres paramètre que tu as cité (allocateur), ne sont propre qu'à StoragePolicy et pas vraiment à la classe, donc je ne vais pas la faire apparaitre ici.

Disons pour la suite que la classe de politique StoragePolicy doit avoir une méthode insert et erase. Je me dis donc que je pourrais utiliser un conteneur séquentiel sur des T* (pointeur pour pas qu'il ai la responsabilité de la durée de vie), problème ca ne compile pas (cf message de Goten pour la raison). Mais rien ne m'empêche de créer un wrapper pour transformer mon conteneur séquentiel en classe de politique :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

template<template<class...>class Container, template<class>class Allocator, class... Arg> struct Wrapper { template<class T> struct StoragePolicy { void insert(); void erase(); //TODO protected: ~StoragePolicy(){} private: Container<T*,Arg...,Allocator<T> > c; }; };   //utilisation Matrix<int,Wrapper<std::vector,std::allocator>::StoragePolicy,OP> m;

---

Voila, c'est plutot comme ca que je vois les choses, mais ce n'est qu'une vision personnel.