Discussion :

[Invité]

Bien avant d'avoir un code rapide, la priorité est au fait d'avoir un code qui fonctionne.

Tous les algorithmes cités plus haut fonctionnent. La différence ne porte que sur leur efficacité. C'est d'ailleurs le contexte de la remarque du GotW

Code :

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

[Guideline] Reuse standard library algorithms instead of handcrafting your own. It's faster, easier, AND safer!

si, par la suite, il s'avère que, pour une raison ou une autre, nous obtenons de mauvais temps d'exécution, il sera beaucoup plus facile de changer de conteneur (et de fonction de recherche) si on doit rechercher "find(tab.begin(),tab.end() " que si on doit rechercher toutes les boucles que l'on a pu créer dans l'ensemble des fonctions qui seront impactées par le changement de conteneur

J'en doute.

D'abord, il ne s'agit pas d'un "si", mais d'un "quand". Les recherches sont très courantes en programmation et dès qu'un conteneur est un peu gros, l'impact en terme de vitesse est énorme (un facteur 50 à 100 pour 1000 éléments, un facteur 25 000 à 50 000 pour un million). Le problème est tellement courant que la STL fournit tous ces algorithmes. Retarder leur utilisationme semble un peu gratuit.

Par ailleurs, la refactorisation ne se limitera pas à changer un algo ou un conteneur. Dans le cas de vecteur triés, on introduit un "contrat" supplémentaire : la préservation de l'ordre. Si l'on travaille sur des structures lourdes, on va remplacer le tri par une indexation. En terme de report, c'est assez lourd, et ça risque d'introduire toutes sortes de risques d'erreurs.

Enfin, dans le cadre d'un projet réel, j'observe que les mauvais choix initiaux ont une fâcheuse tendance à perdurer. Parce que les délais sont trop courts, parce qu'il faut boucler, parce qu'il y a une nouvelle fonctionnalité qu'on considère urgente, parce qu'on ne peut risquer d'introduire une régression à ce stade, les "optimisations" dont tu parles sont souvent reportées, et on finit par livrer quelque chose d'inutilisable.

Francois

[Ekleog]

Oui, en fin de compte, on va utiliser find() pour un vecteur non trié ou une liste, lower_bound() pour un vecteur trié, une fonction membre pour les map, set et conteneurs hachés, et... je ne suis pas certain quoi, pour les multimap et multiset. Ceci veut dire que si l'implémentation change (ou le fait qu'un conteneur non trié le devienne), il faudra changer l'algorithme. [...]

Et, si on n'utilise pas d'algorithmes, il faudra changer l'intégralité du code travaillant sur le conteneur. Au choix, je préfère modifier une ligne !

[Kaamui]

Beaucoup de nouveautés du C++11 et d'anciens algorithmes qui eux ont déjà de la bouteille, comme find, sont pour moi (même si je passe mon temps à réinventer la roue) très utile, car il permmettent de maitnenir un code concis, et toujours (voire plus) compréhensible, pour un utilisateur...lambda

Mais à propos de ces lambdas justement, pour moi c'est comme les foncteurs : réduction du nombre de ligne de code, mais, et beaucoup de monde va surement trouver à en dire, au détriment de la lisibilité du code. Ce que j'aprécie le plus dans un code, c'est de pouvoir le lire comme on lit un bouquin, et avec les lambdas, le but recherché n'est pas clair du tout, et je trouve ça vraiment dommage. je sais que "tout bon programmeur est un fainéant", mais je ne suis pas sur que ces nouveaux outils améliorent les performances, et je suis sur qu'il rendent le code moins compréhensible dans beauuucoup de cas. Donc je ne vois pas pour quel bon motif on doit se servir de ces bêtes là.

[cob59]

Les lambdas peuvent rendre un code plus lisible si on n'en abuse pas. Exemple :

Code :

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

1
2
3
4
5
 
std::vector<std::string> container;
 
auto eLetterRemover = [] (std::string& s) { s.erase(std::remove(s.begin(), s.end(), 'e'), s.end()); };
std::for_each(container.begin(), container.end(), eLetterRemover);

Ça reste propre, compréhensible et ça m'évite de déclarer mon foncteur eLetterRemover trop loin de là où il m'est utile. Cela dit, je trouve quand même que les lambdas utilisées "en r-value" dans un for_each rendent le code hideux, comme en Java où on trouve parfois des {} dans des ().

--edit--
Modifié selon la remarque de JolyLoic.
En y repensant, je trouvais bizarre qu'un STL-algorithm puisse modifier la taille de s

[Kaamui]

Les lambdas peuvent rendre un code plus lisible si on n'en abuse pas. Exemple :

Code :

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

1
2
3
4
5
 
std::vector<std::string> container;
 
auto eLetterRemover = [] (std::string& s) { std::remove(s.begin(), s.end(), 'e'); };
std::for_each(container.begin(), container.end(), eLetterRemover);

Ça reste propre, compréhensible et ça m'évite de déclarer mon foncteur eLetterRemover trop loin de là où il m'est utile. Cela dit, je trouve quand même que les lambdas utilisées "en r-value" dans un for_each rendent le code hideux, comme en Java où on trouve parfois des {} dans des ().

c'est un parfait exemple d'utilisation, et je t'avoue que tu as réussi à me convaincre. Mais on est d'accord, ça peut vite devenir hideux et je penses que c'est exactement cela qu'il faut éviter

[JolyLoic]

Code :

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

1
2
3
 
auto eLetterRemover = [] (std::string& s) { std::remove(s.begin(), s.end(), 'e'); };
std::for_each(container.begin(), container.end(), eLetterRemover);

Attention : std::remove n'efface rien, c'est un piège : http://cpp.developpez.com/faq/cpp/in...ssion_elements

[ShaiLeTroll]

Ancien Delphiste passé depuis 16 mois en C++Builder 2007, je n'ai que peu l'habitude de la STL, ses conteneurs et algos
Je l'ai utilisé exceptionnellement pour la découvrir, les conteneurs comme le Map ou Set m'ont permis de faire un code élégant en STL au lieu le faire manuellement en VCL (le framework de C++Builder)
J'ai gagné du temps sur les Map, j'avais mon propre objet Delphi (à l'époque la Map n'existait vraiment en Delphi), quand j'ai vu que cela existait dans la STL, je n'ai pas hésité !

Je n'ai que vaguement notion sur les Algos STL, je suppose que la plupart sont liés aux Conteneurs STL, ces derniers ne sont pas utilisés où je travaille, les premiers encore moins

Pour les algos, là j'ai déjà plus de difficulté tout comme j'en ai eu au début avec la syntaxe des itérateurs !
le seul algo que j'ai utilisé fut celui de la FAQ : Comment détruire les pointeurs d'un conteneur ?
le Foncteur ajoute une indirection qui n'est pas forcément lisible, la surcharge de l'opérateur () faut être honnête, si tu n'y es pas habitué, tu peux galérer pour comprendre !
J'ai déjà un code très POO, avec un couplage le plus faible que possible avec des Interfaces, très inhabituel où je travaille, si je rajoute en plus d'autres éléments syntaxiques non pratiqués, j'aurais un code illisible pour mes collègues !
On a deux équipes, une en C++ sous Win32, l'autre en C sur micro-proc (16bits je crois), des styles radicalement différents !

Les algorithmes de la STL ont un gros avantage sur les boucles for : ils portent dans leur nom l'objectif même du traitement. La compréhension de l'objectif ... Je trouve que le code se lit alors de façon beaucoup plus fluide.

Si la STL profite à la lisibilité, autant l'utiliser
Si elle amène une complexité syntaxique, j'ai déjà plus de doute (tout dépend des pratiques de l'employeur !)
Si une boucle s'annonce complexe, je l'a commente, je fais même l'inverse !
J'écrit la boucle en français, je décris ce que je vais coder
J'écrit le code réel en laissant les commentaires
Le tout compléter par un cartouche de documentation (param, return, throw ...)
La STL c'est bien quand cela rend le code plus lisible au premier coup d'oeil,
J'ai vu des algos où je travaille fortement tordu pouvant se remplacer juste par une fonction existante dans la RTL (autre partie du framework de C++Builder)

La réponse n'est pas si évidente, il faut s'adapter aussi à la société où l'on travaille, où je suis actuellement, il y a que très peu de POO, pas de séparation Présentation\Modèle (c'est même la pratique inverse).
J'ai utilisé la STL pas curiosité, je me suis même lancé dans la surcharge d'opérateur, comme () ou [] ou même << c'est très intéressant !
Mais ce code est exceptionnel, aucun code des mes autres collègues n'utilisent la STL ou la surcharge d'opérateur !

Il serait maladroit de ma part de laisser du code C++ qui ne respecte pas les standards de la société même si ils sont un peu "vieillo" !

Cela restera donc une expérimentation personnelle, que j'ai fortement documenté car méconnu !
En parallèle, j'ai proposé à mes collègues des approches POO à leur problématique, ce n'est pas parce que l'on ne pratique pas que l'on doit rester fermer, il faut évoluer petit à petit !


[HS]
Dans une ancienne société, en Delphi, un développeur PHP habitué de l'équivalent STL et des itérateurs, a fait tout plein de code avec ces pratiques, quand d'autres collègues (ou moi) ont du reprendre son code, ils se sont arrachés les cheveux car son code ne ressemblait à rien de ce qui était fait habituellement !
Maintenant, les itérateurs, les génériques existent aussi en Delphi, le for a d'ailleurs évolué, il conserve sa forme for i++ mais fourni une version for in équivalent d'un for each
L'évolution ne dénature pas les habitudes, il ressemble très fortement à un for standard contrairement aux horreurs ce fameux développeur

Encore une fois, le respect de la charte de code du langage, de l'outil et de la société doit peser dans la décision de faire code dit "old school" ou du code STL

[tasna]

Personnellement j'utilise les boucles while 99% du temps. Viennent ensuite les boucles do-while à 0.9% et les for à 0.1%.

J'allais écrire "Les boucles while sont hyper simples".
Non toutes les boucles sont simples mais je préfère les boucles while parce que j'aime la représentation.

C'est à dire que je préfère voire ça :

Code :

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

1
2
3
4
5
6
7
 
int LineIx=0;
int LineLen=strlen(Line);
while(LineIx!=LineLen)
{
     ++LineIx;
}

que ça :

Code :

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

1
2
3
4
5
6
 
int LineLen=strlen(Line);
for(int LineIx=0; LineIx<LineLen; LineIx++)
{
     //
}

Je préfère les boucles while parce que dans les boucles for on a un tas d'informations collées et ça peut-être contraignant à lire pour ceux qui utilisent une police de caractères assez petite.

Et puis je préfère séparer les choses. Déclarer d'un côté, tester de l'autre et incrémenter à part.

Après ça dépend des personnes. Certaines peuvent lire et comprendre plus vite des lignes avec pleins d'informations tandis que certaines préfèrent le code avec plus de lignes mais de petite taille.

La seule raison pour laquelle je me mettrai au boucles for c'est si il est prouvé qu'elles s'exécutent plus rapidement.

[Bousk]

Code :

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

1
2
3
4
5
6
7
8
 
for(int LineIx=0,
         LineLen = strlen(Line);
     LineIx < LineLen;
     ++LineIx)
{
     //
}

La lisibilité, ça se cherche/trouve.

[tasna]

Excuses-moi, je ne veux pas être désagréable/méchant mais ton bout de code est... graphiquement moche pour moi.

Lisible ? Pas plus que le tout sur une ligne.

Après c'est chacun ses goûts...

Personnellement je trouve moche un code dont les accolades ne sont pas juste en dessous de leur test conditionnel du genre :

Code :

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

1
2
3
4
5
6
7
 
while(LineIx!=LineLen
                && !Abort
                && cChr!='\n')
{
     ++LineIx;
}

C'est comme ça... je trouve ça moche.
Pour moi un bon code est beau, clair, rapide et ne provoque pas d'erreurs à l'exécution.

Dans mon code les seules choses que vous pourrez trouver entre les parenthèses d'un test conditionnel c'est le test conditionnel, pas de déclaration de variables ni d'assignation.

Tout est question d'habitude. Comme quand je mets Ix après un nom de variable du genre TextIx. Ix = Index. ça signifie qu'elle me sert à accéder à un élément d'un tableau et que ce tableau s'appelle Text.

[Bousk]

Je ne reviens pas sur les conventions d'écriture, chacun a les siennes.

Mais le for tel que je l'ai écris correspond pourtant à tes "critères"
- plus de lignes mais de plus petite taille, et donc clairement plus lisible en cas de multi-initialisation, test ou post-opération
- déclarer d'un côté, tester et incrémenter à part

les accolades ne sont pas juste en dessous de leur test conditionnel

C'est pourtant bien le cas. Mon for et ton while sont identiques, jusque dans leur nombre de lignes.
Un test ne tient pas toujours sur une seule ligne.

Avoir l'incrémentation visible en début permet de ne pas avoir à scroller sur du code parfois long pour trouver ce qu'il se passe en fin de boucle. Si toutefois il s'y passe quelque chose. En debug le temps gagné n'est pas anodin.

Et l'avantage d'un for c'est de contrôler le scope des variables utilisées, ça évite de se trimbaler une variable qui sert d'index dans tout le reste de son scope actuel.

[Kaamui]

Pour en revenir au for, une question me turlupine (mais j'ai peur de faire dévier le topic):

je m'intéresse beaucoup à l'article de Laurent Gomila sur la méta-programmation (et j'y retourne tous les jours pour essayer de comprendre une ligne de code supplémentaire ).

Ma question : pourquoi, alors que la méta-programmation est sans doute la méthode (la philosophie ?) de codage la plus performante, l'utilisation des algorithmes de la STL sont-ils pourtant plus répandus qu'elle ? Du coup, pourquoi ne pas bannir le for au nom de la méta-programmation plutôt ?

Dernière question : pourrait-on (moi je peux pas hein ) concevoir une librairie standard qui utilise la méta-programmation (vu le principe en question j'ai des doutes, mais bon, place à vos lumières ! ) ?

[gbdivers]

Quelques erreurs

Ma question : pourquoi, alors que la méta-programmation est sans doute la méthode (la philosophie ?) de codage la plus performante, l'utilisation des algorithmes de la STL sont-ils pourtant plus répandus qu'elle ? Du coup, pourquoi ne pas bannir le for au nom de la méta-programmation plutôt ?

Alors, pour commencer, la STL utilise, quand c'est possible, la méta programmation (un exemple classique est le choix des algos a utiliser en fonction du type de conteneur)
Et la méta programmation (terme vaste et vague) n'est pas plus performante. Elle répond à une problématique différente : déterminé ce qui peut être optimisé à la compilation et ce qui doit être déterminé à l'exécution. Regarde les expressions template par exemple, tu comprendras les possibilités d'optimisation possible à la compilation.

Dernière question : pourrait-on (moi je peux pas hein ) concevoir une librairie standard qui utilise la méta-programmation (vu le principe en question j'ai des doutes, mais bon, place à vos lumières ! ) ?

Oui et non. Si tu veux créer un vecteur de taille dynamique à l'exécution, tu retomberas sur ce que tu as dans la STL. Si tu veux au contraire avoir des choses déterminées au moment de la compilation, là ça sera applicable. Regarde par exemple Boost.MPL, tu as des vecteurs, des for, etc. le tout déterminé à la compilation (Lis par exemple le Abhrams http://cpp.developpez.com/livres/?page=tous#L0321227255)

C'est une problématique général : savoir déterminer ce qui peut être évalué à la compilation et ce que ne peut pas l'être. La méta programmation ne fait que la première partie

[Klaim]

Je te recommande de verifier le sens de "meta-programation"...

Ma question : pourquoi, alors que la méta-programmation est sans doute la méthode (la philosophie ?) de codage la plus performante

Ca depends ce que tu entends par la, ta phrase est tres vague.
La meta programmation, lorsqu elle est possible à la compilation, permet de laisser le compilateur générer le code executable le plus optimisé pour les différnts cas où ou utilise le code meta-programmé (si on peut dire...)

En gros, ca permet de dire généralement ce qu'on veut comme code, sans le coder, et laisser le compilateur prendre un max d'infos sur le contexte d'utilisation à la compilation pour générer le code final.

Il y a aussi la méta programmation à l'execution, comme la reflexion par exemple, mais C++ n'en fournis quasimment pas (ou très/trop peu). Les template C++ sont de la meta-programmation à la compilation, pas à l'execution. (je precise parceque meta-programmation est un terme trop vague pour decrire de quoi il est question ici).

, l'utilisation des algorithmes de la STL sont-ils pourtant plus répandus qu'elle ?

Ces algorithms sont implémentés en tant que template, donc meta programmation à la compilation (celle dont on parle ici donc).

Pourquoi ils ne sont pqs plus répandus... tu veux dire utilisés plus souvent par les utilisateurs C++ ou bien par les autres languages?

Pour le premier cas, comme souvent, la raison est historique, ou chronologique disons. Comme souligné plusieurs fois dans ce thread, ces algorithmes ont été implémenté avant qu il n y ait les lambda (qui sont extremement recents). Donc a chaque fois que tu as un paramettre qui doit être appellable comme une fonction, soit tu fournis une fonction libre (mais alors tu perds en performance parceque ça passe par un pointeur), soit un fonctor, un objet qui peut être appelé (cas otpimal).
Le problème est que définir un fonctor reviens a définir un type, puis au moins un membre operator() puis l'implémentation. Ce type ne peut pas être définis dans une fonction C++ (oui, on peut définir des class et struct en plein milieu d'une fonction C++, elle ne sera pas utilisable ailleurs) parceque ces types ne sont donc pas visible ailleurs que dans la fonctoin, et comme les fonctions de la librarie standard sont à l exterieur de notre code, et bien ils ne peuvent pas y acceder.
De plus, ecrire ces types est fastidieux, comparé a ecrire par exemple une ligne pour comparer deux objet.

Dans le nouveau C++, C++11 nous avons maintenant:
- les lambda expressions: qui techniquement ne sont qu'un racourcis syntaxique pour définir des foncteurs - mais qui du coup sont extremement pratique puisque tres courts et utilisable directement en argument de la fonction algorithme;
- la restriction des templates ne pouvant pas utiliser en pametre les types définis dqns une fonction a ete levé, ce qui fait ...qu'on peut definir un fonctor dans une fonction et l utiliser ensuite;

Du coup, aujourd'hui, il est tres facile d'utiliser ces algorithmes, alors qu'il y a disons 2 ans, c'était fastidieux, un peu long et surtout nous forcais a ecrire beaucoup de code pour dire quelque chose d esimple.
Aujourd hui c'est l'inverse. (a mon avis)

Pour les autres languages, divers choix de philosophie ont orienté la plupart des languages post-C++ vers des directions différentes concernant la métaprogrammation qui est souvent fournie à l execution au lieu d a la compilation. Cela ne permet pas du tout les mêmes choses.
Les fonctions de la librairie standard sont toutes pensées pour être a la fois génériques et exploitant le fait que le compilateur va exploiter le contexte d'appel de la fonction pour optimiser le code qu'il va générer. Sans meta programmation à la compilation, que les autres languages dont je parle n'ont pas, reproduire cela est presque impossible. Au mieu, on peut optimiser pendant l'execution, mais ca na pas du tout le meme effet.

Des languages comme D par exemple gardent cette meta programmation ala compilation et ont donc le même avantage que C++ de ce coté (et d'autres avantages d'ailleurs) mais fournis en plus la meta programmation a l execution si demandé.

Du coup, pourquoi ne pas bannir le for au nom de la méta-programmation plutôt ?

Parcequ'ils n'ont rien a voir?

Dernière question : pourrait-on (moi je peux pas hein ) concevoir une librairie standard qui utilise la méta-programmation (vu le principe en question j'ai des doutes, mais bon, place à vos lumières ! ) ?

Quasimment toute la librarie standard C++ est meta-programmé...

[Kaamui]

Quelques erreurs

Alors, pour commencer, la STL utilise, quand c'est possible, la méta programmation (un exemple classique est le choix des algos a utiliser en fonction du type de conteneur)
Et la méta programmation (terme vaste et vague) n'est pas plus performante. Elle répond à une problématique différente : déterminé ce qui peut être optimisé à la compilation et ce qui doit être déterminé à l'exécution. Regarde les expressions template par exemple, tu comprendras les possibilités d'optimisation possible à la compilation.

Ok, bon à savoir pour la STL. Pour le terme de méta-programmation, j'évoquais surtout le principe consistant à réduire au maximum les parties de code qui seront traités à l'exécution. Et si ce n'est pas seulement ça la méta-programmation, c'est en tout cas ce principe là que je considère comme ce qu'il peut y avoir de plus performant (en terme d'exécution).

Oui et non. Si tu veux créer un vecteur de taille dynamique à l'exécution, tu retomberas sur ce que tu as dans la STL. Si tu veux au contraire avoir des choses déterminées au moment de la compilation, là ça sera applicable. Regarde par exemple Boost.MPL, tu as des vecteurs, des for, etc. le tout déterminé à la compilation (Lis par exemple le Abhrams http://cpp.developpez.com/livres/?page=tous#L0321227255)

C'est une problématique général : savoir déterminer ce qui peut être évalué à la compilation et ce que ne peut pas l'être. La méta programmation ne fait que la première partie

dans boost.MPL il y a des vecteurs (là j'entends taille dynamique, comme pour les vecteur de la STL) qui sont déterminés à la compilation ? (désolé si je pose des questions bêtes)


EDIT :
@Klaim : Ok bon je me suis bien planté dans mes mots . J'aime pas faire des intervention foireuses

En fait je parlais juste de l'idée de réduire au max le code à déterminer à l'exécution, de l'écriture/approche assez inhabituelle :

Code :

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

1
2
3
4
5
 
template<unsigned int N> struct Fact
{
    enum {Value = N * Fact<N - 1>::Value};
};

Et je pensais que la STL n'était pas codée comme ça.

Ce que je voulais dire (mais je m'exprime mal, ça se voit ), c'est pourquoi ne pas laisser tomber les boucles for pour ce genre de code :

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
 
//exemple de boucle
template <int Begin, int End> struct Boucle
{
    static void Do()
    {
        DoSomething();
        Boucle<Begin + 1, End>::Do();
    }
};
 
template <int N> struct Boucle<N, N>
{
    static void Do() {}
};
 
// Méthode habituelle
for (int i = 5; i < 15; ++i)
    DoSomething();
 
// Avec notre structure Boucle
Boucle<5, 15>::Do();

[Matthieu Brucher]

Tu ne peux pas parce qu'en général tu ne connais pas 5 et 15 à la compilation.
Si tout était connu à la compilation, on n'aurait pas un programme résultat, mais une pou plusieurs valeurs

[Kaamui]

Bonjour,

dans certains cas surement, mais la plupart du temps, je penses notamment à l'utilisation des conteneurs ? les valeurs de retour des méthodes comme begin() et end() ne sont pas résolues avant la compilation ?

EDIT : comment on peut avoir un -1 sur une question ?

[Matthieu Brucher]

Non, ça dépend de ce qu'il y a dans le conteneur qui n'est pas connu à la compilation.

[Lightness1024]

un mpl::vector est dynamique pendant le parsing du code. mais pas plus. une fois l'executable préparé... non.

et d'ailleurs il ne faut pas croire qu'une boucle déroulée s’exécutera plus rapidement qu'une boucle dynamique. la raison à cela étant le "code bloat" et des problèmes de streaming dans le cache L1. Il existe des articles de recherche très poussés sur le sujet du code bloat en C++ qui en parlent.

[Ekleog]

Si on suppose une boucle très répétée, alors le duff's device peut quand même être intéressant si on maitrise bien la taille du cache code et l'influence du déroulement sur le code.

D'ailleurs, le déroulement permet aussi des optimisations plus faciles qu'une extraction de boucle (un simple constant folding suffit, pour certains cas particuliers).