Discussion :

[Florian Goo]

Bonjour à tous,

La convention de nommage de Boost indique que les typedef doivent être suffixées par _t.
Or, le typedef le plus célèbre du C++, std::string, ne suit lui-même pas cette convention.
Dans Boost même, on peut voir des disparités sur ce point. Un exemple avec cette classe tree_node (implémentation générique du pattern composite) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
    template <typename T>
    struct tree_node
    {
        typedef T parse_node_t;
        typedef std::vector<tree_node<T> > children_t;
        typedef typename children_t::iterator tree_iterator;
        typedef typename children_t::const_iterator const_tree_iterator;
 
        T value;
        children_t children;
 
        tree_node();
        explicit tree_node(T const& v);
        tree_node(T const& v, children_t const& c);
        void swap(tree_node<T>& x);
    };

Alors, quand mettre _t, quand ne pas le mettre ?

Un typedef, hors template, c'est avant tout une abstraction. On veut plus ou moins faire oublier quel est le type équivalent, qui serait trop compliqué (un emboitement de templates, par exemple).
Dans ce cas, suffixer le nom du typedef casserait un peu cette abstraction.
Lorsque l'on ajoute _t, on joue plutôt la transparence.

Selon vous, y a-t-il d'autres facteurs qui justifieraient l'ajout d'un suffixe particulier ? Que suivez-vous comme règles, personnellement ?

[Alp]

Personnellement, là où cela me sert le plus (dans le sens pertinent), c'est en métaprogrammation.

J'utilise des typedef intérieurs à ma classe/structure de ce genre :
- type ou
- return_type désignent le type retourné par ma métafonction si c'est un type
- value désigne la valeur retournée par ma métafonction

Bref, ce genre de choses. Après, tout n'est pas parfaitement uniformisé dans Boost donc desfois tu verras des "_t" desfois non.
Personnellement, je trouve que cela fait trop emprunté au C, mais ce n'est que mon avis...

[Jean-Marc.Bourguet]

J'ai le vague souvenir que _t est reserve par POSIX.

Je ne vois pas en quoi les conventions de nommage de boost devraient avoir une influence sur la bibliotheque standard, en particulier quand les composants sont anterieurs a boost.

Il y a une utilite a avoir des conventions de nommages differentes -- ca diminue le risque de collision. Il y a un desavantage: ca diminue l'homogeneite.

Un aspect C++ qui peut pousser a utiliser un suffixe, c'est que les typedefs introduisent un synonyme pour l'ancien type plutot qu'un nouveau type, donc qu'on ne peut pas trop compter sur la possibilite de surcharger.

[Matthieu Brucher]

D'habitude, je nomme mes typedef comme mes classes. Donc si j'ai un suffixe, j'utilise le même suffixe.

[nicroman]

Franchement les conventions de nommages en C++ sont plus des questions de culture d'entreprise que de véritable convention généralisée...

Exemple pour ma part:
Le suffixe _t est utilisé pour un "type" (donc un truc avec constructeurs de recopie, opérateurs et tout le toutim) qui peut être utilisé comme valeur de retour d'une fonction (ou passé par valeur) sans perte de temps/mémoire, sans destructeur virtuel, .... Ca ne veut pas dire que c'est un typedef, juste qu'en hériter va être extrêmement compliqué... Par exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class Fixed32_t  // c'est une classe, mais un vrai 'type'
{
     SInt32_t    m_value; // là c'est juste un typedef vers le bon type de 32 bits
public:
     inline Fixed32_t() {}
 
     inline Fixed32_t(const Fixed32_t& f) : m_value(f.m_value) {}
     inline Fixed32_t& operator=(const Fixed32_t& f) { m_value=f.m_value; return *this; }
     ...
};

J'ai le sentiment que c'est le cas que tu décris.... Recopier un std::string dans un autre std::string est très lent (enfin.... ca appelles malloc donc c'est très lent ).

[Médinoc]

À l'intérieur d'une classe, j'utilise généralement _type.
Surtout dans les classes templates.

[poukill]

Oui quelques libs utilisent ce principe.
Les types sont suffixés par _type

Code :

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

1
2
3
4
5
6
7
8
9
 
typedef IMAGEITERATOR                             ImageIterator;
typedef typename IMAGEITERATOR::LineStartIterator LineStartIterator;
typedef typename IMAGEITERATOR::value_type        value_type;
typedef typename IMAGEITERATOR::difference_type::MoveY difference_type;
typedef typename IMAGEITERATOR::reference         reference;
typedef typename IMAGEITERATOR::index_reference   index_reference;
typedef typename IMAGEITERATOR::pointer           pointer;
typedef std::random_access_iterator_tag           iterator_category;

Après les gouts et les couleurs. L'essentiel je pense c'est d'arriver à un code clair pour soi même et les autres. Car comme le répète souvent Koala, un code est plus souvent lu que compilé/modifié.