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: