Class de traits ou préprocessor ?

Bonjour

Une question à propos de bonnes pratiques... m'est avis que je vais récolter des deux avis :). Voici le problème: j'utilise des smarts pointers dans un projet, ceux de boost. Or, il se trouve que je trouve chiant d'écrire à chaque fois:

Code:

---

1 2	boost::shared_ptr<MaClasse> variable etc bidule truc;

---

Parce que je trouve ça long, d'une part, et parce que je veux me réserver la possibilité (même si la probabilité est très faible) de ne pas être dépendant de boost et de pouvoir changer de smart pointer un jour si je veux. Alors j'écris dans mon header :

Code:

---

1 2 3 4

typedef boost::scoped_ptr<MaClasse> MaClasse_local; typedef boost::shared_ptr<MaClasse> MaClasse_var; typedef boost::weak_ptr<MaClasse> MaClasse_wref;

---

Et j'utilise MaClasse_var (par exemple) dans mon code. Comme je suis paresseux, ce qui est une qualité pour nous autres, informaticiens, j'ai écrit la macro DeclarePointers(MaClasse) (le prénom a été changé) qui définit les typedefs précédents.

Il existe une seconde solution: écrire une classe de traits, que j'utiliserais par exemple de la manière suivante:

Code:

---

1 2 3 4

SmartPrt<MaClasse>::local // code ... SmartPrt<MaClasse>::var // code ... SmartPrt<MaClasse>::wref // code ...

---

Ce qui reste un peu plus chiant à écrire mais économise une macro et a le mérite de ne compiler que les templates effectivement utilisés dans le code.


Selon vous, quel serait la meilleure solution ? Pourquoi ?

Salut,

Avec C++0x et les alias de template, tu pourras faire quelque chose comme ça :

Code:

---

1 2 3 4

template<class T> using sharedPtr = boost::shared_ptr<T>;   //... sharedPtr<monType> ptr;

---

En attendant, F.A.Q : Peut-on créer un alias (typedef) sur des templates ?

Code:

---

1 2 3 4 5

template<typename T> struct smart_ptr { typedef boost::shared_ptr<T> shared_ptr; };

---

Ensuite, l'utilisation smart_ptr<TYPE>::shared_ptr devient indépendante de boost :

Code:

---

smart_ptr<MON_TYPE>::shared_ptr var;

---

Là, le typedef peut être utile :

Code:

---

typedef smart_ptr<MON_TYPE>::shared_ptr shptr_MonType;

---

Pour ce dernier, une macro ou directement, c'est pareil à mon avis.

Salut

Citation:

---

Envoyé par jblecanard

Bonjour

Une question à propos de bonnes pratiques... m'est avis que je vais récolter des deux avis :). Voici le problème: j'utilise des smarts pointers dans un projet, ceux de boost. Or, il se trouve que je trouve chiant d'écrire à chaque fois:

Code:

---

1 2	boost::shared_ptr<MaClasse> variable etc bidule truc;

---

Parce que je trouve ça long,

---

Mais bon, c'est quand meme pas la mort non plus :p

Citation:

---

d'une part, et parce que je veux me réserver la possibilité (même si la probabilité est très faible) de ne pas être dépendant de boost et de pouvoir changer de smart pointer un jour si je veux.

---

C'est déjà une meilleure raison, mais... pourquoi :question:

Peut etre devrais tu déjà t'interroger sur la durée de vie de ton projet, car, si c'est un projet à court terme, les raisons que tu pourrais avoir de t'orienter vers une autre bibliothèque risquent de se faire rares :P

Citation:

---

Alors j'écris dans mon header :

Code:

---

1 2 3 4

typedef boost::scoped_ptr<MaClasse> MaClasse_local; typedef boost::shared_ptr<MaClasse> MaClasse_var; typedef boost::weak_ptr<MaClasse> MaClasse_wref;

---

---

C'est, à mon avis, ce qui pourrait nécessiter le moins de manipulation dans l'éventualité où tu souhaite passer à une autre bibliothèque... pour autant qu'à pointeur équivalent, tu aies une interface équivalente ;) (ce qui n'est pas forcément certain :aie:)

Citation:

---

Et j'utilise MaClasse_var (par exemple) dans mon code. Comme je suis paresseux, ce qui est une qualité pour nous autres, informaticiens, j'ai écrit la macro DeclarePointers(MaClasse) (le prénom a été changé) qui définit les typedefs précédents.

---

Est-ce vraiment plus facile :question: je n'en suis pas persuadé...

Citation:

---

Il existe une seconde solution: écrire une classe de traits, que j'utiliserais par exemple de la manière suivante:

Code:

---

1 2 3 4

SmartPrt<MaClasse>::local // code ... SmartPrt<MaClasse>::var // code ... SmartPrt<MaClasse>::wref // code ...

---

---

La classe de traits présenterait sans doute aussi pas mal d'avantages, mais il faut les chercher plus du coté de la possibilité de choisir la politique de gestion des pointeurs que du coté de la facilité... après tout, tu ne gagnerait que l'écriture de boost::... est-ce que cela vaut réellement la peine :question:

Citation:

---

Ce qui reste un peu plus chiant à écrire mais économise une macro et a le mérite de ne compiler que les templates effectivement utilisés dans le code.

---

Il y a de grandes chances pour qu'il en aille de même pour les macros, étant donné que leur mode de fonctionnement est basé sur le remplacement d'une expression donnée par une autre ;)

Citation:

---

Selon vous, quel serait la meilleure solution ? Pourquoi ?

---

Si, vraiment, tu veux "économiser" quelques caractères, je dirais que les deux solutions font des choses différentes. Dans certaines situations les macro seront préférables, et, dans d'autres, ce serait la classe de trait qui présenterait le plus d'avantages, sans qu'il soit possible de déterminer "laquelle est meilleure que l'autre".

Mais, encore une fois, en as-tu vraiment besoin :question:

Ne pourrais tu pas, tout simplement, te contenter d'une directive using :question:

Citation:

---

Envoyé par koala01

pour autant qu'à pointeur équivalent, tu aies une interface équivalente (ce qui n'est pas forcément certain )

---

J'y ai pensé, mais pour des smart pointers, tu peux presque en être sûr à l'avance, les interfaces étant les constructeurs (sur T* et par copie) et l'opérateur d'affectation.

Citation:

---

Envoyé par koala01

Est-ce vraiment plus facile :question: je n'en suis pas persuadé...

---

Rien que sur un petit projet, je peux te dire que oui, c'est vraiment agréable ! Ne serais ce qu'au niveau de la lisibilité. L'économie de caractères, c'est juste pour mon confort en temps que dev. Et les usings, j'en utilise déjà parce que je bind sur plusieurs librairies, alors je préfère ne pas en abuser.

Citation:

---

Envoyé par koala01

Il y a de grandes chances pour qu'il en aille de même pour les macros, étant donné que leur mode de fonctionnement est basé sur le remplacement d'une expression donnée par une autre

---

Certes oui. La question se soulève alors : est ce que un "typedef NomTemplate<Type> NomALaCon;" provoque à lui seul la compilation du template ?

Ce sujet, c'est un peu du chipotage, mais je sais qu'il y en a sur ce forum qui aiment le chipotage :mrgreen:

Salut,

Citation:

---

Envoyé par jblecanard

Certes oui. La question se soulève alors : est ce que un "typedef NomTemplate<Type> NomALaCon;" provoque à lui seul la compilation du template ?

---

A mon sens, il ne s'agit pas d'une instanciation explicite ou implicite. Donc je dirais non. Mais il est vrai que pour les template, en général je préfère 'qualifier' le compilateur si ces problématiques d'instanciation sont importantes (code bloat essentiellement).

@koala : ça a un intérêt de passer par une classe trait pour déterminer les smart pointeurs à utiliser. En terme de design, découpler 2 modules (surtout là où ils sont vraiment orthogonaux) n'est jamais inutile. De plus, même s'il est peu probable de changer de bibliothèque de smart ptr sur un projet, une partie du code peut faire l'objet de reuse dans un autre projet n'utilisant pas Boost. Ce découplage facilitera grandement cette réutilisation.

Citation:

---

Certes oui. La question se soulève alors : est ce que un "typedef NomTemplate<Type> NomALaCon;" provoque à lui seul la compilation du template ?

---

Non..

Citation:

---

Envoyé par jblecanard

J'y ai pensé, mais pour des smart pointers, tu peux presque en être sûr à l'avance, les interfaces étant les constructeurs (sur T* et par copie) et l'opérateur d'affectation.

---

En théorie, effectivement...

En pratique... va savorir :P

Citation:

---

Rien que sur un petit projet, je peux te dire que oui, c'est vraiment agréable ! Ne serais ce qu'au niveau de la lisibilité. L'économie de caractères, c'est juste pour mon confort en temps que dev. Et les usings, j'en utilise déjà parce que je bind sur plusieurs librairies, alors je préfère ne pas en abuser.

---

Attention, je suis le premier à reconnaitre les bienfaits des macros (si elles sont utiles), des typedefs et des classes de traits, mais je persiste à dire que, si ta seule motivation est de remplacer boost::weak_ptr<UnType> par autre chose, fusse plus simple, n'est clairement pas suffisante :aie:

Citation:

---

Ce sujet, c'est un peu du chipotage, mais je sais qu'il y en a sur ce forum qui aiment le chipotage :mrgreen:

---

On peut aimer le chipotage, et on peut même envisager de le faire dans du code en exploitation.

Mais tout est toujours une question d'utilité: chipoter pour chipoter est une très mauvaise chose, alors que le fait de chipoter pour éviter de se retrouver bloqué suite à de mauvaise décisions de conception au départ, cela peut avoir tout son sens ;)

Citation:

---

Envoyé par 3DArchi

@koala : ça a un intérêt de passer par une classe trait pour déterminer les smart pointeurs à utiliser. En terme de design, découpler 2 modules (surtout là où ils sont vraiment orthogonaux) n'est jamais inutile. De plus, même s'il est peu probable de changer de bibliothèque de smart ptr sur un projet, une partie du code peut faire l'objet de reuse dans un autre projet n'utilisant pas Boost. Ce découplage facilitera grandement cette réutilisation.

---

Si tu relis mon intervention, tu remarqueras que je parle des avantages de la classe trait, et que je mets en avant la possibilité de choisir la politique de gestion des pointeurs ;)

Mais, de la manière dont jblecanard présente les choses, on pourrait croire qu'il s'oriente vers quelque chose comme

Code:

---

1 2 3 4 5 6 7 8

template <typename T> struct smart_ptr { typedef boost::weak_ptr<T> weak; typedef boost::shared_ptr<T> shared; /* et tous les autres, dans la même structure */ };

---

et, là, tu remplace simplement l'écriture de boost::some_ptr<UnType> par smart_ptr<UnType>::some ... Du point de vue de l'écriture, cela ne change rien :D

Par contre, s'il se dirige, effectivement, vers quelque chose comme

Code:

---

1 2 3 4 5

template <typename T, typename Policy struct smar_pointer { typedef typename Pölicy<T> ptr_type; };

---

il en va évidemment tout autrement :D

Citation:

---

Envoyé par koala01

Mais tout est toujours une question d'utilité: chipoter pour chipoter est une très mauvaise chose, alors que le fait de chipoter pour éviter de se retrouver bloqué suite à de mauvaise décisions de conception au départ, cela peut avoir tout son sens ;)

---

Complètement d'accord. Mon projet actuel n'a pas absolument besoin d'être bien géré sur ce point, mais je me suis posé la question pendant le dev et me suis dit que le débat pourrait m'être utile à terme.

Citation:

---

Envoyé par koala01

Par contre, s'il se dirige, effectivement, vers quelque chose comme

Code:

---

1 2 3 4 5

template <typename T, typename Policy struct smar_pointer { typedef typename Pölicy<T> ptr_type; };

---

il en va évidemment tout autrement :D

---

Effectiveme, ça se sert à rien sinon. J'avais un peu de mal avec les classes de traits, là j'ai parfaitement compris la valeur ajoutée potentielle :ccool: