Discussion :

[koopajah]

Bonjour,

J'ai une petite interrogation à propos des classes de traits lorsque l'on développe des conteneurs génériques (tels que STL ou boost). Prenons l'exemple suivant:

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
18
19
20
21
22
 
template<class T>
struct A
{
     T value;
      typedef T type;
};
 
template<class Conteneur>
struc Traits
{
   typedef Conteneur::type type;
};
 
template<class Conteneur>
void maFonction(Conteneur c)
{
    //def 1
   Conteneur::type a;
    //def2
    Traits<Conteneur>::type b;
}

D'après ce que j'ai compris c'est la seconde définition qui doit être utilisée, pourtant les tests que j'ai réalisés fonctionnent tout aussi bien avec la première. Pourquoi dois-je alors faire intervenir une classe de traits?

Merci d'avance!!

[dok3]

typiquement le trait devrai etre un parametre template de ta fonction, il permet de fournir le corps des operations de base effectuee sur un "concept" et non pas sur un type precis.

ainsi l'utilisation d'un trait pour un "simple" typedef n'apporte pas grand chose, pur avoir une meilleur vision des capacite des traits regarde le code de la std::string

edit : je me suis mal exprimer, disons qu'un trait fourni une "interface" sur un concept (des char, des stream, etc). la specialization du trait pour un type donne fourni le corps des methods pour chacun des types du concept
(jme suis peut etre encore mal exprimer la )

[Laurent Gomila]

Pour reprendre un peu ce que dok3 t'expliquait, une classe de traits n'a pour but que de fournir des caractéristiques sur un type donné, tout en restant conforme a une certaine interface qui permettra d'utiliser ton trait là où il est attendu.

Petit exemple avec numeric_limits par exemple, qui fonctionne plus ou moins de cette manière :

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
18
19
20
21
22
23
24
25
template <typename T> struct numeric_limits;
 
template <> struct numeric_limits<float>
{
    static float max() {return FLT_MAX;}
    enum {IsIntegral = 0};
};
 
template <> struct numeric_limits<int>
{
    static int max() {return INT_MAX;}
    enum {IsIntegral = 1};
};
 
// ...
 
template <typename T>
void Fonction(T x)
{
    if (x < numeric_limits<T>::max())
        cout << "Blah blah" << endl;
 
    if (numeric_limits<T>::IsIntegral)
        cout << "Blah blah" << endl;
}

[JolyLoic]

Imagine que tu ait une classe que tu ne peux pas modifier, et qui ait un typedef sur la donnée nommé "Type" et non pas "type". Ou même que ton Conteneur soit un type de base, genre int. Tu seras alors bien content de pouvoir lui ajouter en externe l'information nécessaire pour le faire entrer dans ton framework.

[koopajah]

Rebonjour tout le monde;

Merci pour vos réponses déjà je crois que je comprends à peu près ce que vous voulez dire. Cependant l'exemple de numerics_limits indique une specialisation des classes.

Si on prend l'exemple de la classe graph_traits de Boost :
http://www.boost.org/libs/graph/doc/graph_traits.html

Il semble qu'ils définissent simplement les types des sommets, des arcs, ou des itérateurs sur les structures en ne faisant que des typedef typename Graph::type type;

Dans ce cas, quelle est la différence entre cette méthode et le fait de faire directement Graphe::type type; dans notre algorithme? Puisque de toute facon il faudra faire quand meme graph_traits<Graphe>::type type; si on utilise les traits!

Merci!

[Laurent Gomila]

Si un jour tu souhaites utiliser une autre classe de graphe qui définit les mêmes concepts mais pas avec les mêmes noms, tu pourras alors faire ceci :

Code :

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

1
2
3
4
5
6
7
8
9
template <>
struct graph_traits<MyGraph>
{
    typedef typename MyGraph::VertexDescriptor   vertex_descriptor;
    typedef typename MyGraph::EdgeDescriptor     edge_descriptor;
    typedef typename MyGraph::AdjacencyIterator  adjacency_iterator;
    typedef typename MyGraph::OutEdgeIterator    out_edge_iterator;
    // ...
};

L'interêt des traits n'est pas d'être utilisé tel quel, mais d'être spécialisé pour adapter un type particulier à un framework existant.

[koopajah]

Ok je crois que j'ai compris.

Merci en tout cas!