Discussion :

[master20]

Bonjour,

En programmant avec STL, J'ai une classe A (contenant deux attribut string X ey Y) et j'ai eu besoin d'une list<A> pour manipuler mes données.

Je voudrais afficher les éléments de ma liste en ordre croissant de l'attribut X.
Pour cela, j'ai passé par l'algorithme sort() qui reçoit entre un foncteur (qui est une méthode de la classe Foncteurs)qui prend deux objets de A (a1 et a2) et compare a1.X et a2.Y

Jusqu'ici, tout est correct. mon problème est: je voudrais également afficher mes données par ordre croissant de l'attribut Y. Pour cela, j'ai fait de même. j'ai donner à l'algorithme sort() un foncteur qui prend également deux objets de A (a3 et a4) et compare a3.Y et a4.Y. Cependant, lors de la compilation, il y a une ambiguité pour le foncteur qui trie suivant X et celui suivant Y. Ils ont la même signature, donc le compilateur ne sait pas quel foncteur prendre pour le bon tri. Comment je peux contourner ce problème ?

Merci

[Arzar]

Bonjour,
Peux tu nous montrer à quoi ressemble tes deux foncteurs et comment tu les passes à la fonction sort ?

[koala01]

Salut,
Le plus simple est de donner des noms différents à tes foncteurs, vu que, de toutes manières, tu les appelleras sans doute dans des contextes différents

Tu pourrait avoir un

Code :

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

1
2
3
4
5
6
7
8
 
struct lessByX
{
    bool operator()(A const & first, A const & second) const
    {
        return first.x() <second.x();
    }
};

et un

Code :

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

1
2
3
4
5
6
7
8
struct LessByY
 
{
    bool operator()(A const & first, A const & second) const
    {
        return first.Y() <second.Y();
    }
};

Tu fournirais donc "LessByX" si tu veux trier ta collection sur base de l'attribut X et LessByY si tu veux le faire sur base de l'attribut Y

Après, si l'idée est de travailler de manière générique (avec les templates), il est bon de se rappeler le bon vieil adage de

all problems in computer science can be solved by another level of indirection .

et d'envisager, pourquoi pas,
1- la création de deux flags proches de

Code :

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

1
2
struct XNeeded{};
struct YNeeded{};

2- la spécialisation d'un "getter" générique sous la forme de

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
template<typename Flag>
struct FlaggedGetter;
template<>
struct FlaggedGetter<XNeeded>
{
    std::string const & operator()(A const & a) const
    {
        return a.x();
    } 
};
template<>
struct FlaggedGetter<YNeeded>
{
    std::string const & operator()(A const & a) const
    {
        return a.y();
    } 
};

3- l'utilisation d'un foncteur générique proche de

Code :

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

1
2
3
4
5
6
7
8
template <typename Flag>
struct MyGenericLesser
{
    bool operator()(A const & first, A const & second) const
    {
        return FlaggedGetter<Flag>()(first) < FlaggedGetter<Flag>()(second);
    }
};

Et le tour serait joué

[oodini]

envisager, pourquoi pas,
1- la création de deux flags proches de

Code :

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

1
2
struct XNeeded{};
struct YNeeded{};

Pourquoi utiliser deux structures plutôt qu'un enum ?

[Bousk]

N'y aurait-il pas une histoire qu'un enum déclare des symboles, donc prend de la mémoire, là où une structure si elle n'est pas utilisée, ne consomme rien d'autre que des lignes de codes ?
Ca semble anecdotique, mais c'est toujours une information intéressante.

[ternel]

N'y aurait-il pas une histoire qu'un enum déclare des symboles, donc prend de la mémoire, là où une structure si elle n'est pas utilisée, ne consomme rien d'autre que des lignes de codes ?
Ca semble anecdotique, mais c'est toujours une information intéressante.

Je suis curieux d'en apprendre plus à ce sujet. As-tu une référence à conseiller?

[Bousk]

Non en plus je dis de la merde.
Un enum n'existe qu'à la compilation mais ne prend pas de mémoire.
Ce sont les variables constantes qui en prennent.

http://www.programmersheaven.com/mb/...num-data-type/

enums are not allocated in memory - they exist only on compilation stage. They only exist to tell compiler what value is FEB for example. When code runs - there is no enums there anymore.

[koala01]

En fait, c'est une simple question d'habitude...

Une classe ou une structure vide étant garantie de taille nulle, il n'y a aucun overhead à les utiliser, mais, je trouve cela "plus propre":

Tu respecteras beaucoup plus facilement l'OCP si tu dois rajouter un critère de tri avec des flags sous forme de structure que si tu dois le faire avec une énumération, dans le sens où il "suffit" de créer le flag sous la forme d'une structure, alors que tu devrais aller modifier ton énumération

De plus, cela permet, le cas échéant, de n'avoir besoin de connaitre que les flags qui t'intéressent, vu qu'ils peuvent parfaitement être définis, ainsi que la spécialisation de fonction qui l'utilise, dans des fichiers d'en-têtes différents (même si on peut discuter de ce choix ), alors qu'avec une énumération, tu auras obligatoirement connaissance de l'ensemble des flags, et il y a fort à parier que l'ensemble des implémentations se trouvera dans un même fichier

Bref, il est beaucoup plus facile de "diviser pour mieux régner" avec des structures qu'avec une énum, même si le résultat est sensiblement identique

[ternel]

Cet argument me plaît. Merci pour l'explication.

[koala01]

De rien

Je pourrais d'ailleurs te donner un autre argument, un peu plus tirée par les cheveux, je dois l'avouer:

Si tu travailles avec une énumération, mettons, pour l'exemple:

Code :

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

1
2
3
4
5
6
enum MyEnum
{
    firstValue, //=0
    secondValue, //=1
    /* ... */
};

Tu peux travailler aussi bien avec des spécialisations de

Code :

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

1
2
template <MyEnum>
struct MonFoncteur;

qu'avec des spécialisations de

Code :

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

1
2
template <int>
struct MonFoncteur;

Dans le premier cas, il n'y aura pas de problème : il faudra bel et bien utiliser ton foncteur sous la forme de
MonFoncteur<firstValue> car toute tentative d'utiliser MonFoncteur<0>devrait se solder par une erreur de compilation du genre de

impossible de convertir 1 en MyEnum

(enfin, ca dépend encore du compilateur, je présumes )

Par contre, dans le deuxième cas, il n'y aurait strictement aucun problème, ni au moment de définir la spécialisation ni au moment d'utiliser ton foncteur parce que 0 est, bel et bien... un int.

Tu te laisses donc la possibilité, si tu décides de travailler avec la deuxième forme proposée, de perdre l'information que représente ton énumération, ce qui est finalement fort dommageable en terme de relecture du code, en plus de te permettre, pourquoi pas, fournir une spécialisation pour ton foncteur avec une valeur qui ne fait pas partie de ton énumération (ce qui la rendrait caduque).

La seule solution qu'il te resterait pour avoir un minimum d'information sur le critère utilisé si tu venais à spécialiser le second cas sous la forme de

Code :

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

1
2
3
 
template 
struct MonFoncteur<10> // 10 n'étant pas une des valeurs énumérées

serait... d'aller voir dans le code ce qui est réellement utilisé .

Tu m'objecteras sans doute que "bah, je n'ai qu'à faire attention en fournissant la déclaration anticipée de mon foncteur", et tu n'as pas tout à fait tord.

Le problème, c'est que tu feras sans doute bien attention lors de la déclaration anticipée de la première série de foncteurs que tu écriras.

Puis, trois mois plus tard, tu te rendras compte qu'il te faut une deuxième série de foncteurs variant selon les même critères, mais dont le comportement sera totalement différent de ceux dont tu dispose déjà.

Je ne suis pas sur du tout que tu penseras (parce que je ne suis pas du tout sur que j'y penserai encore moi-même ) encore à "faire bien attention" lors de la déclaration anticipée de cette série de foncteurs

Par contre, si tu travailles avec des flags prenant la forme de structures vides, tu n'auras pas ce problème car, même si tu fournis une spécialisation proche de

Code :

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

1
2
3
 
template 
struct MonFoncteur<InexistantFlag> // Inexistant flag n'étant pas une des structures existantes

il n'y aura aucun problème, même dans trois mois, même si tu veux baser une autre série de foncteur sur les même critères : le compilateur te fera quoi qu'il arrive savoir qu'il ne connait pas "InexistantFlag"

[ternel]

Quoiqu'en C++11 tu puisse utiliser une enum class, totalement typé.

[koala01]

Quoiqu'en C++11 tu puisse utiliser une enum class, totalement typé.

Effectivement, mais j'avais prévenu que cet argument était quelque peu tiré par les cheveux

Et puis, quand on voit le nombre de projets qui n'osent pas passer à des compilateurs plus récents que VC++6 ou, pour les projets plus récents, le nombre d'énumérations que tu as parfois, on peut estimer qu'il faudra pas mal de temps avant que les énumération de classes ne remplacent les énumérations classiques que l'on trouve dans ces projets.

Ceci dit, même si tu prends la décision d'utiliser systématiquement les énumérations de classes dés le début d'un projet récent, il ne faut pas perdre de vue mon premier argument, qui reste tout à fait valable, même (et surtout ) en C++11