Discussion :

[yan]

Bonjour suite � cette discutions :
http://www.developpez.net/forums/d79...lacant-switch/
je cr�� ce poste pour avoir vos avis. Mon probl�me est assez simple. J'ai une structure compos�e de int et string. Je dois pouvoir trier un vecteur en fonction de n'importe quels membres. Un point important, c'est un vecteur utilis� pour de l'ihm et qui sera tri� de temps en temps par l'utilisateur. Voulant optimiser un minimum, ma premi�re version est tr�s lourde � relire et donc autant plus complexe � maintenir (d'o� mon poste au d�part):

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
switch(m_sortFlag)
    {
        case DESCENDINGORDER | IDMAILBOX:
            qStableSort 
                    (
                        m_internal.begin(),
                        m_internal.end(),
                        std::binary_negate<compareIdMailBox>(compareIdMailBox()) 
                    );
 
            break;
        case ASCENDINGORDER | IDMAILBOX:
            qStableSort 
                    (
                        m_internal.begin(),
                        m_internal.end(),
                        compareIdMailBox() 
                    );
 
            break;
 
        case DESCENDINGORDER | IDEMAIL:
           qStableSort 
                    (
                        m_internal.begin(),
                        m_internal.end(),
                        std::binary_negate<compareIdEmail>(compareIdEmail()) 
                    ); 
            break;
        case  ASCENDINGORDER | IDEMAIL:
           qStableSort 
                    (
                        m_internal.begin(),
                        m_internal.end(),
                        compareIdEmail() 
                    ); 
            break;
...
}

fcharton m'as propos� une solution, que je trouve bien plus pertinente par rapport � mon probl�me. Un simple pr�dicat avec un param�tre dans le constructeur qui contiendra le switch.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
 
class Sorter {
private:
  int SortType;
public:
  Sorter(int st) : SortType(st) {}
  bool operator()(type &t1,type &t2) { 
    switch SortType {
       case ... : return...
    }
  }
};

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
qStableSort (v.begin(),v.end,Sorter(sorttype));

Compar�au code de d�part, ce trie sera moins rapide, car le switch sera pr�sent � chaque it�ration, mais faux probl�me, car le trie d�pend du temps "humain" et donc bien assez rapide pour une iHM et donc un humain. Et surtout, la lisibilit� du code et sa maintenance y gagne consid�rable!
Comme il est toujours int�ressant de confronter les id�es,

�tes vous d'accord avec ce raisonnement? ou trouvez vous cela absurde?
Ou
Dans quelle mesure le C++ moderne peut rend la maintenance plus facile?

[loufoque]

Quel rapport avec "C++ moderne blablabla" ?
La solution 2 est � jeter selon moi. La premi�re est simplement pas terrible parce que c'est pas bien factoris�.

Sinon pourquoi ne pas plut�t maintenir des indexes que de tout trier � chaque fois...

[yan]

La solution 2 est � jeter selon moi

pourquoi? Du moment qu'il est suffisamment rapide pour une IHM?

La premi�re est simplement pas terrible parce que c'est pas bien factoris�.

Tu ferais comment?

Sinon pourquoi ne pas plut�t maintenir des indexes que de tout trier � chaque fois...

Tu veut dire dire des tableaux d'index?
Ben � chaque nouveaux items ou modif d'un item, il faudra maintenir � jours tous les tableaux. Si tu rajoute un nouveau param�tre, faut rajouter un tableau d'index. Pour la personne qui va �crire le code, il devrais si retrouver. Mais pour le gas qui va reprendre le code?

Ou tu parle d'un truc comme boost.Multi-index?

[loufoque]

pourquoi? Du moment qu'il est suffisamment rapide pour une IHM?

Parce que �a n'a pas de sens.
Le choix du membre s'effectue avant, ce n'est pas une partie de l'�tat du crit�re de comparaison.

Tu ferais comment?

Une solution simple est de faire une table qui associe identifiieur du champ au crit�re de comparaison associ�.

Tu veut dire dire des tableaux d'index?

Non, je veux dire des indexes. Comme dans un livre.

[yan]

Une solution simple est de faire une table qui associe identifiieur du champ au crit�re de comparaison associ�.

Tu veut dire une sorte de tableau de pr�dicat/fonction?

[metagoto]

La m�thode 2 ne me semble pas bonne du tout. Elle ne fait que d�caler le "probl�me" � un autre endroit (le switch) tout en �tant plus p�nalisante en terme d'op�rations effectu�es.

Je suis d'accord avec loufoque pour un syst�me de lookup

Pourquoi pas un truc dans ce genre ?

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
26
27
28
29
 
template<typename T, typename R = bool>
struct sorter
{
  enum pred {
    box_asc = 0 //ASCENDINGORDER | IDMAILBOX
   ,box_desc    //DESCENDINGORDER | IDMAILBOX
   //,..
  };
 
  typedef std::tr1::function<R (T, T)> pred_type;
 
  static pred_type table[];
};
 
template<typename T, typename R>
typename sorter<T, R>::pred_type sorter<T,R>::table[]
= {
  compareIdMailBox()
 ,std::binary_negate<compareIdMailBox>(compareIdMailBox())
  //,..
};
 
 
typedef sorter<int> sortint;
 
//int m_flag = sortint::box_desc;
 
std::stable_sort(m_internal.begin(), m_internal.end(), sortint::table[m_flag]);

[Invit�]

ce n'est pas une partie de l'�tat du crit�re de comparaison.

Pourquoi? Si tu consid�res que ton crit�re compare des objets, le sens et la nature de la comparaison en sont des param�tres, qui repr�sentent des �tats. Si tu dois faire pas mal de ces comparaisons (dans des tris, mais aussi lors de recherches ou d'affichages) et si les crit�res utilis�s d�pendent d'�lements complexes, tu auras int�ret � les centraliser (c'est un peu ce que tu ferais avec une table, remarque).

Une solution simple est de faire une table qui associe identifiieur du champ au crit�re de comparaison associ�.

Ca, ca ne va fonctionner que si les crit�res sont peu nombreux... Suppose maintenant qu'ils puissent se combiner entre eux : tu vas trier ta table dans un ordre, puis selon plusieurs crit�res, et �ventuellement en fonction de modes de calculs diff�rents (param�tres d'affichage du champ, en valeur, en %, en indice, disons), ta table va vite devenir importante.

Le lien aux "champs", je me m�fierais... Tr�s vite, tu vas te retrouver avec des champs calcul�s, totaux, �volution, taille du document, message, fichier, et l�...

Non, je veux dire des indexes. Comme dans un livre.

Pareil, ca marche si ton tableau est petit (parce qu'il faut garder ces index en m�moire), et si on ne le recalcule pas (sinon il faut tout garder � jour). Les index, c'est bien si tu as peu de colonnes, ou si tu utilises toujours les m�mes. Ce n'est pas incompatible avec les approches pr�c�dentes, soit dit en passant : on stocke les index dans le conteneur d'origine, � cote des objets, et on programme leur utilisation dans la fonction de tri.

Ce que j'essaie de dire, c'est qu'il est utile de centraliser le code de comparaison, parce que c'est typiquement le genre de chose qui a tendance � se compliquer assez vite de sous cas, et de cas particulier. C'est d'ailleurs l'approche suivie par les grid fournies dans la plupart des IHM : pour trier une colonne, on appelle une fonction de comparaison de lignes, param�trable pas la colonne de tri et un certain nb d'�lements suppl�mentaires... Il y a une raison � cela.

Personnellement, une table me va tout aussi bien qu'un foncteur. Je trouve juste l'approche foncteur plus propre (m�me si moins efficace): une table, faut la cr�er, la g�rer, la d�truire.

@metagoto : remplacer un switch par une �num, c'est un peu de la triche, non? (et puis, surtout, une �num c'est monodimensionnel, ca va te sauter � la figure tr�s vite, ca...)

Francois

[metagoto]

@metagoto : remplacer un switch par une �num, c'est un peu de la triche, non? (et puis, surtout, une �num c'est monodimensionnel, ca va te sauter � la figure tr�s vite, ca...)

Je ne sais pas, c'est le truc le plus simple auquel j'ai pens� pour "nommer" les index de lookup
Apr�s, je ne fais que proposer..
Je viens de tester, �a compile et �a fonctionne (je sais, ce n'est pas un crit�re en soi). Si �a n'avait pas �t� le cas, je l'aurai pr�cis� aussi!