Typedefs internes en C ++ - bon style ou mauvais style?

Question

Quelque chose que je me suis fait souvent ces derniers temps est de déclarer typedefs pertinents pour une classe à l'intérieur de cette classe, c'est à dire

class Lorem
{
    typedef boost::shared_ptr<Lorem> ptr;
    typedef std::vector<Lorem::ptr>  vector;

//
// ...
//
};

Ces types sont ensuite utilisés ailleurs dans le code:

Lorem::vector lorems;
Lorem::ptr    lorem( new Lorem() );

lorems.push_back( lorem );

Raisons pour lesquelles je l'aime:

• Il réduit le bruit introduit par les modèles de classe, std::vector<Lorem> devient Lorem::vector, etc.
• Il sert comme une déclaration d'intention - dans l'exemple ci-dessus, le Lorem classe est destinée à être un décompte de références via boost::shared_ptr et stocké dans un vecteur.
• Il permet la mise en œuvre de changer - c'est à dire si Lorem besoin d'être modifié pour être intrusif, d'un système de référence comptés (via boost::intrusive_ptr) à un stade ultérieur, ce qui aurait un impact minimal sur le code.
• Je pense qu'il est 'beau' et est sans doute plus facile à lire.

Raisons pour lesquelles je ne l'aime pas:

• Il y a parfois des problèmes avec dépendances - si vous souhaitez intégrer, par exemple, un Lorem::vector dans une autre classe, mais seulement besoin (ou envie) de déclarer avant le Lorem (par opposition à l'introduction d'une dépendance sur son fichier d'en-tête), puis vous finissez par avoir à utiliser les types explicites (par exemple, boost::shared_ptr<Lorem> plutôt que d' Lorem::ptr), ce qui est un peu incohérent.
• Il peut ne pas être très commun, et donc plus difficile à comprendre?

J'essaie d'être objectif avec mon style de codage, de sorte qu'il serait bien d'avoir quelques autres opinions sur elle afin que je puisse disséquer mon réfléchir un petit peu.

Answer 1

Il sert comme une déclaration d'intention - dans l'exemple ci-dessus, le Lorem classe est destiné à être un décompte de références par boost::shared_ptr et stockés dans un vecteur.

C'est exactement ce qu'il ne veut pas faire.

Si je vois 'Foo::Ptr" dans le code, je n'ai absolument aucune idée de si c'est un shared_ptr ou un Foo* STL (a ::pointeur typedefs T*, rappelez-vous) ou que ce soit. Esp. si c'est un pointeur partagé, je n'ai pas fournir une définition de type, mais garder le shared_ptr utiliser explicitement dans le code.

En fait, je n'ai pratiquement jamais utiliser typedefs à l'extérieur du Modèle de la Métaprogrammation.

Le TSL n'a ce genre de chose tout le temps

La STL de conception avec des concepts définis en termes de fonctions de membre et imbriquées typedefs est un historique cul-de-sac, moderne, modèle de bibliothèques de l'utilisation libre des fonctions et des classes de traits (cf. Coup de pouce.Le graphique), car elles ne permettent pas d'exclure des types intégrés de la modélisation de la notion et parce qu'il est l'adaptation de types qui n'ont pas été conçus avec le modèle donné des bibliothèques concepts dans l'esprit plus facilement.

Ne pas utiliser la STL comme une raison de faire les mêmes erreurs.

Answer 2

Les typedefs sont ceux sur lesquels la conception et les traits fondés sur les politiques s'appuient sur C ++. La puissance de la programmation générique en C ++ découle donc des typedefs eux-mêmes.

Answer 3

Typdefs sont sont certainement un bon style. Et tous vos "raisons j'aime" sont bonnes et correctes.

Sur les problèmes que vous avez avec cela. Eh bien, en avant de la déclaration n'est pas un saint graal. Vous pouvez tout simplement la conception de votre code afin d'éviter multi niveau des dépendances.

Vous pouvez déplacer typedef en dehors de la classe, mais la Classe::ptr est tellement plus joli alors ClassPtr que je ne fais pas cela. C'est comme avec les espaces de noms comme pour moi, les choses de rester connecté dans le champ d'application.

Parfois, je n'ai

Trait<Loren>::ptr
Trait<Loren>::collection
Trait<Loren>::map

Et il peut être par défaut pour toutes les classes du domaine et avec une certaine spécialisation de certains d'entre eux.

Answer 4

La STL fait ce genre de chose tout le temps - les typedefs font partie de l’interface de nombreuses classes de la STL.

 reference
iterator
size_type
value_type
etc...
 

sont tous des typedefs qui font partie de l'interface pour différentes classes de modèles STL.