le C++ "moderne" et la maintenance de code

**yan** · 17/08/2009, 22h26

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** · 17/08/2009, 22h46

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** · 17/08/2009, 22h57

Envoyé par loufoque

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?

Envoyé par loufoque

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** · 17/08/2009, 23h44

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** · 17/08/2009, 23h48

Envoyé par loufoque

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** · 18/08/2009, 08h36

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é · 18/08/2009, 08h56

Envoyé par loufoque

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).

Envoyé par loufoque

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à...

Envoyé par loufoque

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** · 18/08/2009, 09h04

Envoyé par fcharton

@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!

Invité · 18/08/2009, 09h13

Envoyé par metagoto

Je ne sais pas, c'est le truc le plus simple auquel j'ai pensé pour "nommer" les index de lookup

Oui, ce que je veux dire, c'est que, dans le cas de tableaux affichés dans des grilles, on se retrouve assez vite avec des critères de tris compliqués.

Par exemple, on commence avec une table simple, des objets en ligne, leurs champs en colonne, un champ par colonne, un critère de tri aussi. Ta structure en table est faite pour cela...

Dès le début il va déjà falloir tout couper en deux, parce qu'il y a deux ordres de tri.

Ensuite, on va voir arriver des demandes du type :
- tri multicritère
- affichage de sommes (en ligne ou en colonne)
- % d'une colonne par rapport à une autre (ou évolution)
- affichage du rang d'une ligne vs une colonne,

et ainsi de suite.

Gérer une table de critère de tris par colonne, ca signifie énumérer à l'avance toutes les colonnes possibles, et leur associer à l'avance une fonction spécifique, c'est souvent difficile ou très lourd... C'est ce que je veux dire par "sauter à la figure"

Francois

**white_tentacle** · 18/08/2009, 09h18

Personnellement, je ferais bêtement un prédicat par type de tri, ça me semble le plus simple. Avec éventuellement une fonction qui te renvoie le bon prédicat à partir du paramètre de tri.

**metagoto** · 18/08/2009, 09h32

Envoyé par fcharton

Dès le début il va déjà falloir tout couper en deux, parce qu'il y a deux ordres de tri.

Ensuite, on va voir arriver des demandes du type :
- tri multicritère
- affichage de sommes (en ligne ou en colonne)
- % d'une colonne par rapport à une autre (ou évolution)
- affichage du rang d'une ligne vs une colonne,

et ainsi de suite.

Gérer une table de critère de tris par colonne, ca signifie énumérer à l'avance toutes les colonnes possibles, et leur associer à l'avance une fonction spécifique, c'est souvent difficile ou très lourd... C'est ce que je veux dire par "sauter à la figure"

C'est pas faux. Mais bon, dans le cadre de l'exemple proposé dans le premier post, factoriser avec un simple lookup est une alternative qui me paraît justifiée. Après, c'est sur que si on doit implémenter un tableur ou un sgbd, ça va être rapidement limitant

Quoique, pour le reverse order, y a sûrement moyen de bidouiller avec sizeof(table)/sizeof(elem) et un modulo pour appliquer le reverse order automatiquement. Mais bon, ça va pas être sympa pour le gars qui va devoir maintenir le code, on est d'accord

**yan** · 18/08/2009, 10h01

Je trouve l'explication de fcharton très claire et pertinente.
Le problème, n'est pas vraiment la perf. Je doit trier sur des choses simple (int, string) un vecteur utilisé par une ihm.
Le faite de centralisé le choix du trie dans le foncteur est beaucoup plus simple à maintenir et a faire reprendre. Et la perte de perf se justifie par la lisibilité du code et que l'IHM ne sera pas plus lente pour un humain.

Invité · 18/08/2009, 11h34

Envoyé par metagoto

Quoique, pour le reverse order, y a sûrement moyen de bidouiller avec sizeof(table)/sizeof(elem) et un modulo pour appliquer le reverse order automatiquement. Mais bon, ça va pas être sympa pour le gars qui va devoir maintenir le code, on est d'accord

Le reverse order, mine de rien, c'est une vraie saleté avec la STL... Pour la fonction de comparaison, les bibliothèques futées renvoient trois valeurs : -1, 0 et +1 (le zéro correspondant à l'égalite). Pour inverser un tri, tu multiplies par -1 le résultat de la fonction de comparaison, et c'est comme au paradis : les premiers sont les derniers et inversement. Les valeurs égales, elles, demeurent inchangées, si tu as un tri stable, elle ne bougent pas, si tu as un tri multicritère, le second critère s'applique.

Avec un critère booléen, comme dans la STL, c'est plus compliqué, car on a trois cas :

1- a<b
2- b<a
3- ni l'un ni l'autre (ce qui veut dire qu'ils sont égaux)

Pour inverser le tri, on ne peut faire la négation du tri de départ, il faut gérer les trois cas (sinon, dans le cas d'un tri multicritère, ou d'un algo de tri stable, on va avoir des surprises, puisque les valeurs égales ne le sont plus).

En pratique, la meilleure façon sera probablement de découpler la comparaison proprement dite et la gestion de l'ordre de tri... Un foncteur le fera en gérant l'ordre comme un paramètre à part (et probablement en ayant une comparaison qui renvoie un résultat entier), dans le cas d'une table, il faut sans doute faire de même (seconde indirection dans la table, ou paramètre passé à la fonction de tri)

Francois

**yan** · 18/08/2009, 11h40

Envoyé par fcharton

Pour inverser le tri, on ne peut faire la négation du tri de départ

Oui j'ai vue cela après un plantage

J'avais pas pensé à l'égalité

**Arzar** · 18/08/2009, 12h49

Envoyé par loufoque

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

Envoyé par fcharton

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.

Ma parole vous vous êtes donné le mot ?

Qu'est-ce que vous entendez par ces "tables qui associent un champ à un critère de comparaison" ? Comment est-ce que cela s'utilise ?

**metagoto** · 18/08/2009, 13h28

Envoyé par fcharton

Le reverse order, mine de rien, c'est une vraie saleté avec la STL... Pour la fonction de comparaison, les bibliothèques futées renvoient trois valeurs : -1, 0 et +1 (le zéro correspondant à l'égalite). Pour inverser un tri, tu multiplies par -1 le résultat de la fonction de comparaison, et c'est comme au paradis : les premiers sont les derniers et inversement. Les valeurs égales, elles, demeurent inchangées, si tu as un tri stable, elle ne bougent pas, si tu as un tri multicritère, le second critère s'applique.

C'est pas faux!

Juste pour vérifier, j'ai tenté d'implémenter mon idée à base de sizeof pour appliquer un binary_negate automatiquement si on dépasse le nombre d'élements de la table.

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
template<typename T, typename R = bool>
struct sorter
{
  enum pred {
    box_asc = 0
   ,box_desc // = 1  
  };
  typedef std::tr1::function<R (T, T)> pred_type;
  static pred_type table[];
  static pred_type lookup(unsigned int index);
};
 
template<typename T, typename R>
typename sorter<T, R>::pred_type sorter<T,R>::table[]
= {
  std::less<T>() // une seule entrée
};
 
 
template<typename T, typename R>
typename sorter<T, R>::pred_type sorter<T, R>::lookup(unsigned int index)
{
  typedef typename sorter<T, R>::pred_type pred_type;
  static unsigned int count = sizeof(sorter<T, R>::table)/sizeof(pred_type);
  return index >= count
    //ici le modulo
    ? pred_type(std::binary_negate<pred_type>(sorter<T, R>::table[index%count]))
    : sorter<T, R>::table[index];
}
 
int main()
{
  std::vector<int> m_internal;
  m_internal.push_back(3);
  m_internal.push_back(4);
  m_internal.push_back(2);
  m_internal.push_back(1);
 
  typedef sorter<int> sortint;
  sortint::table;
 
  int m_flag = sortint::box_asc; // index = 0 --> std::less
  std::stable_sort(m_internal.begin(), m_internal.end()
                  ,sortint::lookup(m_flag));
 
  // echo
  std::copy(m_internal.begin(), m_internal.end()
           ,std::ostream_iterator<int>(std::cout,","));  
 
  // volontairement out of bound
  m_flag = sortint::box_desc; // index = 1 --> !std::less
  std::stable_sort(m_internal.begin(), m_internal.end()
                  ,sortint::lookup(m_flag));
 
  // echo
  std::copy(m_internal.begin(), m_internal.end()
           ,std::ostream_iterator<int>(std::cout,","));
 
  return 0;
}

Je déconseille ça. Mais ça divise par 2 le nombre d'entrées dans la table

Invité · 18/08/2009, 15h02

Envoyé par Arzar

Ma parole vous vous êtes donné le mot ?

Qu'est-ce que vous entendez par ces "tables qui associent un champ à un critère de comparaison" ? Comment est-ce que cela s'utilise ?

C'est du "para-SQL"... En gros, on a un tableau qui affiche des objets en lignes et des propriétés de ces objets en colonnes. Si on faisait du SQL, ce seraient des entrées dans une table en ligne et des champs en colonne.

Maintenant, on veut que, quand on clique sur un header de colonne du tableau, la grille se trie sur le critère de la colonne, donc le champ correspondant de la table... Donc, on va associer à chaque colonne un champ, et un critère de tri... Et, pour éviter de perdre du temps, on va mettre ces critères dans une LUT.

Ensuite, on pourrait se dire que notre grille peut montrer n'importe quel champ (c'est paramétrable). On peut donc choisir, à l'exécution, ce qu'on montre dans chaque colonne. Il faut donc associer un critère de tri à chaque champ...

Voila,

Francois

**dzada** · 18/08/2009, 22h56

Salut,
Pour ma part, j'applique un principe simple dans mes developpement IHM(suite a differentes casseroles):

_même si ca semble rapide, il faut optimiser car 1ms+1ms+....et au bout d'un certain temps tout ton code devient lent, unitairement, acceptable, mais globalement, lent, au bout de 2 mois de dev

_si l'optimisation est sale, je suis d'accord qu'on ne peut pas l'accepter simplement, parceque ca va plus vite, mais souvent, c'est qu'on a pas assez reflechit a comment faire mieux. (c'est facile a dire, et des fois, on ne trouve pas, néanmoins, plus je monte d'appli, plus je me rend compte que c'est vrai, demander des idées à d'autres si on ne voit pâs soi meme, ou prévoîr un refactoring dans le planning, mais en dernier recours, car on aura pas le temps et/ou effet chateau de carte, changer ce truc quand on a l'idée demande de repenser plein de chose => pas le temps/courage

donc, le principe moderne = -optimisé mais +lisible est un faux probleme

pire, imagine en embarqué, les gros projets doivent etre optimisé et un mini evolutif si ils durent, 10 ans en moyenne

**metagoto** · 18/08/2009, 23h54

Dans quelle mesure le C++ moderne peut rend la maintenance plus facile?

Juste histoire d'agrémenter le thread avec des illustrations en couleur et des gros caractères, voici une présentation intéressante de Stepanov:
Professionalism in Programming. Presented at Adobe Systems Inc., April 17, 2003
http://www.stepanovpapers.com/Profes...rogramming.pdf
Notamment, pages 4 à 13, il montre un refactoring d'une portion de code GUI.
La suite de la présentation est très intéressante, ne serait-ce que pour cerner le point de vue de Mr Stepanov.
Mis à part le fait que l'architecture machine et les pointers sont les deux mamelles du C++ moderne (

), on insistera sur "code is documentation". Pris au pied de la lettre, ça nous octroie tous les droits pour factoriser et condenser au maximum pour peu que ce qui en résulte exprime l'essence même du problème (alors après le fait que celà soit exprimé à un ordre 4 ou 5 en généricité, c'est une autre histoire

).

**Aurelien.Regat-Barrel** · 22/08/2009, 16h58

Personnellement, je ne comprends pas qu'on se préoccupe du coût d'un switch vs un appel de fonction. Sincèrement, pour moi on baigne en plein délire. Les performances ça se joue avant tout au niveau mémoire. Quand on a 50.000 objets à trier, c'est les accès / recopies / allocations qui font mal, pas un malheureux aiguillage. fcharton met le doigt sur le vrai problème : le choix du bon algo de tri, c'est là qu'il faut passer du temps à bien analyser ai lieu de sortir le canon pour tuer la mouche

A part ça, je trouve la proposition de fcharton nettement plus simple et lisible. Ma vision du "C++ moderne", c'est que la complexité et lourdeur d'écriture de certains "tricks" devraient servir à coder des composants / bibliothèques plus simples à utiliser, et pour moi ce code :

Code :

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

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

l'emporte sans appel sur celui là :

Code :

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

std::stable_sort(v.begin(), v.end(), sortint::table[sorttype]);

désolé metagoto

le C++ "moderne" et la maintenance de code

C++

Partager

Partager