Discussion :

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

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[3DArchi]

Salut,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

smart_ptr<MON_TYPE>::shared_ptr var;

Là, le typedef peut être utile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

typedef smart_ptr<MON_TYPE>::shared_ptr shptr_MonType;

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

[koala01]

Salut

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

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

Alors j'écris dans mon header :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 )

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 je n'en suis pas persuadé...

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

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

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

[jblecanard]

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.

Est-ce vraiment plus facile 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.

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

[3DArchi]

Salut,

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.

[Goten]

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

Non..

[koala01]

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

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

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

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

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

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[jblecanard]

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.

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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