Discussion :

[yan]

Cependant, je trouve qu'il y a un certain danger à penser trop vite en terme de "haut niveau" (ici d'algorithmes), parce que cela risque de figer certains éléments de la conception avant d'avoir correctement diagnostiqué le problème.

C'est un peu le problème qu'on rencontrait aux beaux jours de l'approche objet, quand on se précipitait pour construire une hiérarchie de classes avant d'avoir fini l'analyse. On perdait souvent, ensuite, un temps précieux à revenir sur ces erreurs initiales. On retrouve ce genre de problème aujourd'hui quand quelqu'un essaie, trop fort et trop tôt, d'exprimer un problème en terme de design patterns.

Je crois que les algorithmes (ceux de haut niveau, du moins) sont plus utiles dans un second temps, quand le problème est à peu près dégrossi, et qu'il s'agit de passer d'un code initial, souvent bricolé et fait main, à quelque chose de plus abstrait, qui sera plus durable et évolutif.

Je suis tout à fait d'accord avec ton point de vue. Pour mes codes, j'ai pris l'habitude de coder par itérations.
1- Je commence par un code rapide sans optimisation et avec un minimum de classe et sans chercher à bien comprendre les lib exploitées. => je cherche à avoir un code qui me servira de base. C'est un code de faisabilité, et parfois c'est juste un main. L'utilisation des algo sont au minimum.
2- je re-factor cela en une première architecture => c'est ma première version de travaille.
3- j'adapte l'architecture au besoin pendant la suite du développement => Mes classes évoluent en fonction des problèmes rencontrés. J'essai d'exploiter les algo.
4- je fais une mise au propre quand je considère une partie de l'architecture comme stable. Retour au 3.

Mes classes ont souvent évoluées 2-3 fois.

Je trouve que cela me permet d'avoir un code vivant. Et pour moi un code vivant va évoluer dans le bon sens.

Par contre depuis qu'il y as les lambda, je n'hésite plus à remplacer les for par des for_each quand je n'ai pas besoin de l'indice.

[victor_gasgas]

@Joel F : Il me semblait bien avoir vu ton nom dans le pdf sur boost.simd http://www.google.fr/url?sa=t&rct=j&...cIN_Hg&cad=rja. C'est vrai que je serais moi aussi très intéressé par un tuto, même si le pdf offre quelques explications.
Par contre si je comprend bien boost.simd utilise boost.proto pour les expressions templates avec boost::pack<T,N>?

Cette digression à part, je donne le point de vue d'un étudiant : on passe nos séances de tps et d'algorithmie à appréhender cela - ce qui, soyons d'accord, est tout à fait normal. Néanmoins, je pense que pour un projet en production, on ne devrait pas avoir à réinventer la roue (syndrome NIH) à chaque fois, tellement ça prend du temps rien qu'en test, maintenabilité, etc.

Après je pense que cela lève un autre problème comme une S(T)L "relativement" pauvre comparé à d'autre langage. Par exemple pourquoi devoir pour énormément de projets devoir coder et re-coder la gestion datetime (même si boost couvre ce manque)?
Beaucoup de librairie de boost on étaient intégrée dans C++11 - array, bind, function, chrono, thread, smart_ptr pour ne citer qu'elles, mais pourquoi pas datetime, stringalgo et plein d'autres?

Bonne journée à tous!

P.S. Avant de m'attirer les foudres, je sais bien que la S(T)L permet de faire beaucoup de chose, surtout avec C++11

[gbdivers]

Quelqu'un peut me donner l'équivalent de ceci avec la stl ?

Code :

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

1
2
for(int i=0; i < myArray.Count; ++i)
    myArray[i] = GenerateSomething(myArray[i], i);

histoire de savoir si c'est possible avec autant voire moins de code

Tu prends un exemple de code minimaliste, où l'on a besoin d'avoir l'indice, on reste donc sur de la boucle for quasiment classique. Il y a quand même beaucoup d’algorithmes qui n'ont pas besoin de connaître i (et pour rappel, [] n'est pas ce qu'il y a de plus performant en terme d'accès)

Donc dans tous les cas, il faudra créer cette variable, ce qui ne permet pas de réduire proprement le code

Code :

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

1
2
3
4
5
6
7
// avec range-based for
int i = 0;
for (auto& value, myArray) { value = GenerateSomething(value, i++); }
 
// avec for_each et lambda
int i = 0;
for_each (begin(myArray), end(myArray), [&i] (auto& value) { value = GenerateSomething(value, i++); });

Donc clairement, si tu pars d'un code minimaliste, l'utilité sera très limité

[Lightness1024]

je suis vraiment désolé de ne pas prendre le temps de lire les 4 pages, donc surement que ce que je dis a déjà été mentionné.
mais pour répondre a l'OP:

1: pourquoi pas tant que faisable et ne termine pas en un code plus long et dispersé a lire
2: "systématique" c'est bien le problème dans ton topic Mr gbdivers. je ne vois pas comment la STL peut fournir tous les algorithmes du monde. évidemment que c'est impossible.
3: excellent, il faudrait plus de ce genre de méthodes chez les profs. rentrer dans la tête des ptis bleus que réinventer la roue carrée saymal.
4: non. désolé je ne le pense vraiment pas. parfois écrire un for en 3 lignes c'est plus clair qu'appeller un algo avec des itérateurs de partout qui fait une ligne de 160 caractère de long avec du begin() et end() a n'en plus finir.
5: a mon avis il y en a une infinité

- pour rajouter un peu de mon avis perso, je ne connais pas d'implémentation des algos STL qui tourne en multi-thread. avec un for en 2 secondes tu fais #pragma parallel for.
ou alors tu peux utiliser les libs SIMD d'intel, ou meme Trust pour faire tourner des algos en CUDA.

- écrire un transform avec le code déporté a 15km dans une structure, voire meme dans un autre fichier (car certaines coding rules disent 'une classe=un fichier') c'est ridicule. C++11 règle ce problème avec les lambdas, ce n'est pas pour rien.

et franchement je peux continuer comme ca longtemps, tu me dirais bannir for(;;) au profit de while() je dirais ok car for n'est pas une structure de contrôle standard en algorithmique, alors que while() l'est.
mais bannir au profit de la STL c'est juste pas possible, la STL ne fourni pas tout.

voila désolé de rompre le fil du topic

[koala01]

Déjà le stagiaire, il est là aussi pour apprendre. Donc lui faire endosser la part de productivité, c'est un peu gros.

Je crois qu'il faut lui apprendre à etre productif, malgré tout, étant donné que c'est quand meme ce qu'il devra faire par la suite (une fois sorti du stage)...

Si l'on se contente de le placer dans une situation "d'exercice de style", il n'y a plus aucun avantage à faire un stage par rapport à ce qu'il trouve à l'école, non plus

Il ne faut en effet pas s'attendre à ce qu'il soit aussi productif que quelqu'un qui a ne serait ce que deux ou trois ans d'expérience, mais l'idée est quand meme de lui permettre de faire son expérience et que son employeur puisse profiter de ce que le stagiaire met au point, meme s'il le fait peut etre plus lentement qu'un autre

En plus, il est parfois bien plus compétent que les employés techniquement parlant.

plus compétant que certains, très certainement, sous condition quand meme (s'il a eu un bon prof, qui ne lui a pas appris le C With Classes, s'il a eu des cours corrects de POO, si... )

Mais il faut qu'il puisse se heurter à la "dure réalité" et travailler sur du code de production aussi, car, c'est une chose de partir "de rien" et donc d'avoir une liberté de choix, mais c'en est une autre que de devoir assumer des choix qui ont été faits par d'autres qui, avec un peu de malchance, ne sont plus dans la boite depuis bien longtemps

Et enfin même un employé lambda est aussi là pour apprendre. Après qu'il s'en tape c'est une autre affaire.

Je crois que l'informatique, c'est comme le domaine médical: il faut se tenir très sérieusement à jour, et surtout, etre en mesure de se remettre en question

Quant à Qt, ca me semble normal de préférer l'utilisation des structures de Qt pour Qt avant l'emploi de la stl...

Je ne suis pas du tout d'accord avec toi...

Les structures de Qt sont particulièrement bien faites, mais elles présentent malgré tout un inconvénient majeur: elles sont propres à Qt...

Si tu bases ta partie "business" sur Qt, toute ton application va dépendre de Qt, et tu n'auras pas d'autre choix, si, pour une raison ou une autre, tu décides un jour de changer de bibliothèque, que de "tout casser" et de reprendre ton projet à zéro.

Cela pourrait etre considéré comme l'occasion de "faire mieux", mais cela implique que l'ensemble du développement est à refaire malgré tout, et donc un temps de refonte important.

Par contre, si tu limites la dépendance envers Qt à la partie "vue" (et à une partie de l'aspect "contrôleur"), tu restes beaucoup plus libre de changer de point de vue, voire, d'utiliser le business pour une application totalement différente, utilisant une autre bibliothèque IHM

[deuz59]

Cela rejoint parfaitement mon point de vue qui se résume en "Penser du QUOI vers le COMMENT plutôt que l'inverse"

Pour ce faire, tout plein de bonnes questions et bonnes pratiques sont recensées dans ce bouquin dont je ne cesserai jamais de recommander la lecture :
http://www.scribd.com/doc/50311486/coder-proprement

Quoi de plus frustrant quand on cherche à corriger/faire évoluer un programme que d'avoir à deviner ce que ça fait à travers ce qu'y est fait.
La bonne démarche serait que le code nous amène d'abord à comprendre ce qui est fait pour cibler précisément le bout de code à revoir, le "comment ça le fait et pourquoi ça le fait pas bien"

L'informatique est un MOYEN et la solution de facilité revient trop souvent à se réfugier dans ses connaissances et donc d'en faire trop tôt un BUT (peut être aussi la faute à la formation qui devrait être davantage orientée dans ce sens ???)

Un idéal serait de réussir à faire d'abord un squelette de code avec que des appelles de méthodes aux noms explicites,avec une organisation par niveau d'abstraction et seulement au niveau le plus bas mettre un petit TODO "à implémenter" ==> sorte de DSF qui ne resterait au final qu'à (faire) implémenter, si toutefois aucune API existante ne propose pas déjà une implémentation toute faite

[shenron666]

Tu prends un exemple de code minimaliste, où l'on a besoin d'avoir l'indice, on reste donc sur de la boucle for quasiment classique. Il y a quand même beaucoup d’algorithmes qui n'ont pas besoin de connaître i

l'inverse est aussi vrai : il y a beaucoup d'algorithmes qui ont besoin de connaitre l'index

(et pour rappel, [] n'est pas ce qu'il y a de plus performant en terme d'accès)

moins performant que n'importe quel algorithme de la stl ? j'en doute

Donc dans tous les cas, il faudra créer cette variable, ce qui ne permet pas de réduire proprement le code

d'où mon exemple qui démontre si besoin en était que supprimer for serait contre productif

en fait, c'est juste un faux débat
ou alors on supprime aussi while et on retourne au goto

[gbdivers]

l'inverse est aussi vrai : il y a beaucoup d'algorithmes qui ont besoin de connaitre l'index

Les algorithmes de la STL ne sont pas incompatible avec un compteur (le preuve, j'ai donné du code qui les utilises)

moins performant que n'importe quel algorithme de la stl ? j'en doute

Attention, l'opérateur [] est très très couteux en terme de performance. En interne, il fait le calcul récupérer l'adresse du premier élément + sizeof(T) * n (donc une addition et une multiplication) alors que les algorithmes de la STL peuvent aussi utiliser l'accès séquentiel (++it). Selon les algorithmes, les performances ne seront pas les mêmes du coup (sauf à réécrire le for sans utiliser [])
C'est l'un des points forts de la méta-programmation : optimiser les algorithmes utilisés en fonction des conteneurs et des types de données. Et ça peut même aller beaucoup plus loin en terme d'optimisation (là on sort de la STL, mais c'est pour dire que le home-made n'est pas forcement ce qu'il y a de plus optimisé)

d'où mon exemple qui démontre si besoin en était que supprimer for serait contre productif

Ce n'est pas une démonstration

Et cela reste productif, car même si on ne gagne rien en terme de quantité de lignes de code, on gagne en robustesse et en évolutivité : toujours grâce à la méta-programmation, les implémentations des algorithmes pourra évoluer et être optimisé (algorithme plus adapté en fonction du type de données, utilisation de l'accélération matérielle, etc.) de manière transparente pour l'utilisateur. Alors qu'avec du code home-made, il faudra réaliser ces optimisations soit même

[Invité]

Par contre, si tu limites la dépendance envers Qt à la partie "vue" (et à une partie de l'aspect "contrôleur"), tu restes beaucoup plus libre de changer de point de vue, voire, d'utiliser le business pour une application totalement différente, utilisant une autre bibliothèque IHM

Jpense que on parle pas du meme niveau.
Si on code tout en Qt, cest quon a fait le choix de se servir de Qt partout (model et view/controller)
Si on code en Qt que view/controller cest quon a fait le choix de pas avoir de dep sur le model.

Mais dans tous les cas, si on a choisit de se servir de Qt dans un module je pense quíl faut jouer le jeu.
(apres j'avouerais que jai jamais rencontre un cas ou le Q supplementaire justifiait son emploi par rapport a la STL, mais ca me gene pas de voir un tel code)

Enfin pour les stagiaires, uiui on est daccord, c'est pas non plus le monde des bisounours

[yan]

Les structures de Qt sont particulièrement bien faites, mais elles présentent malgré tout un inconvénient majeur: elles sont propres à Qt...

Si tu bases ta partie "business" sur Qt, toute ton application va dépendre de Qt, et tu n'auras pas d'autre choix, si, pour une raison ou une autre, tu décides un jour de changer de bibliothèque, que de "tout casser" et de reprendre ton projet à zéro.

Pourtant Qt n'est pas que de l'IHM.
Ce que tu dit est pareil pour n'importe quel framework. Remplace Qt par Boost dans ton paragraphe par exemple et se sera tout aussi vrai;p

Juste pour dire, que choisir un framework pour l'exploiter au maximum as aussi beaucoup d'avantage. Voir peut être plus que moins (ou pas ).

Par exemple (comme on parle de Qt) pour un de mes dernier projets on as décidé de baser l'application entièrement sur Qt. En l'exploitant au maximum j'ai :
* des threads avec eventloop
* des communications inter thread par event ou signal/slot
* des manipulations d'objet par des algo concurrent
* des states machines
* des plugins
* un cache
* des QVariant(sorte de void* typé)
* des meta data.
* un peux de 3D
* de l'affichage d'image char, short, float, complexe, bayer,...
* des smart pointeurs et des lambda dans des QVariant.
* de l'IHM

Pour faire fonctionner tout cela, j'ai dû utiliser 3 mutex au maximum pour optimiser 2-3 petites choses. Et au finale, la partie GUI de Qt n'est qu'une petite partie de l'application. Au contraire Qt à permis une architecture multi thread très robuste et très facilement extensible par plugin.

[skypers]

Je trouve que l'argument conceptuel est le plus important dans le message de l'OP. Entre une grosse for pour compter le nombre d'occurences matchant un critère et un std::count_if, il n'y a pas photo pour moi.

En revanche, je trouve curieux l'étonnante façon qu'ont les gens d'utiliser des lambdas simples qui rendent le code plus long et moins trivial alors qu'une boucle aurait suffit. Coder reste un art, tous les outils sont bons, il faut juste savoir les utiliser au bon endroit. C'est toujours la même histoire.

[Obsidian]

Il faut aussi tenir compte de quelque chose que l'on oublie parce que c'est évident : les algos de la STL utilisent ces boucles. Si on supprime les boucles du langage, la STL ne peut plus fonctionner.

S'il s'agit seulement de mettre une frontière entre le programmeur et tout ce qui se trouve en dessous de cette bibliothèque, alors il faut donner des cours de « programmation STL », ce qui peut effectivement devenir une méthode de développement, labellisée de surcroît pour être aisément identifiable dans le contexte inter-professionnel.

Par contre, il ne faut pas interdire le reste, ni même rendre cette méthode obligatoire. C'est une approche comme une autre, et étudier d'autres angles d'attaques reste très intéressant. Ne serait-ce que parce qu'il faudra toujours, à terme, des gens pour développer Boost et la STL. Si on apprend directement aux gens à utiliser l'existant et le plus approprié sans se soucier de la manière dont ça fonctionne, on va perdre beaucoup de savoir-faire.

Et à dire vrai, je pense que cette vision des choses est celle de Java : plus de goto, plus de gestion manuelle de la mémoire ou presque, et une machine virtuelle qui établit un environnement au runtime pour gérer à l'exécution ce qui serait insoluble à la compilation. On a vu ce que ça a donné : une flopée de gens qui s'y sont orientés parce que « c'est comme le C mais sans les pointeurs ». Mais le coût en ressources et la manière de faire fonctionner tout cela est resté complètement abstrait à la plupart d'entre eux.

Du coup, on voit effectivement apparaître énormément de technologies « de haut niveau » et orientées entreprise, ne serait-ce que dans la manière de les nommer (J2EE, JBoss, etc) qui sont généralement très bien conçues et qui demandent de s'y investir entièrement tant elles sont étendues, mais très peu de choses côté bas niveau. Et moi, c'est justement ce que je recherche dans le C++ : l'exhaustivité préférée à la simplicité et la possibilité de redescendre « tout en bas », sans impliquer de technologies sous-jacentes si elles ne sont pas nécessaires.

[Joel F]

Attention, l'opérateur [] est très très couteux en terme de performance. En interne, il fait le calcul récupérer l'adresse du premier élément + sizeof(T) * n (donc une addition et une multiplication) alors que les algorithmes de la STL peuvent aussi utiliser l'accès séquentiel (++it).

cooli quand meme, t[i] se transforme souvent en mov+lea, le calcul d'qdresse est en general fait en amont dans le pipeline avec un bypass classique qui rend l'adresse disponible pour le mov avant la terminaison de l'etage.

Si ton compilo generer des add/imul pour faire un [], va falloir en changer.
Et quand bien meme il le ferait, le temps a fetcher la donner depuis le cache ou la memoire va etre preponderant.

[pvincent]

Je connais peu le C+++ et pas grand chose de la STL, mais cette discussion me remet en mémoire un langage des années 70-80 bien oublié de nos jours: l'APL d'IBM http://en.wikipedia.org/wiki/APL_(programming_language). C'était un langage conçu pour le calcul scientifique et basé sur la notion (et la notation) d'opérateur et l'utilisation de signes cabalistiques: il permettait de concentrer en une ligne de code (de longueur raisonnable) ce qui demandait souvent 15 à 20 lignes dans les langages de l'époque (C et FORTRAN) et bien sûr, sans écrire de boucle.

Le seul inconvénient, c'est que mon pauvre cerveau attrapait des migraines quand je voulait comprendre ce que faisait la ligne en question!

C'est à mon avis une des raisons principales pour lesquelles il a sombré dans l'oubli. Le danger me semble toujours présent et je trouve bien agréable de trouver dans la Netlib, Lapack et autres des subroutines Fortran d'époque qui conviennent à mes besoins, dont je comprend comment me servir en un tournemain et qui compilent sans problème avec les compilateurs dernier cri.

[JolyLoic]

Je pense en lisant certains commentaire que l'on n'a pas tous compris la question de la même manière. J'ai l'impression que certains ont lu :

Faut-il supprimer "for" du langage ?
A mon sens la réponse est non sans même hésiter. On a toujours goto, après tout

Pour ma part, j'ai lu :

Faut-il déconseiller l'usage de for (et implicitement while et do-while), c'est à dire le considérer comme la solution à utiliser en dernier, quand on s'est rendu compte que les autres ne marchent pas ?

Et là, mon avis est bien plus favorable. Je pense que si je pouvais écrire du code C++11 (et ne pas avoir à compiler avec des outils d'il y a 15 ans), mon code contiendrait très peu de boucle for écrites à la main (les range-based for loop, elles, seraient assez courantes).

[koala01]

Jpense que on parle pas du meme niveau.
Si on code tout en Qt, cest quon a fait le choix de se servir de Qt partout (model et view/controller)

Pas forcément...

Voir plus loins ce que je dis au sujet du projet sur lequel je bosse pour l'instant

Si on code en Qt que view/controller cest quon a fait le choix de pas avoir de dep sur le model.

C'est, justement, un choix des plus intéressant, quand on y pense...

Cela permet, tout en gardant le mème business, qui est considéré comme stable, de lancer pourquoi pas, plusieurs projets utilisant d'autres bibliothèques "NIH" (comprends : qui ont réinventé la roue pour tout ce que l'on trouve dans la STL), quasiment sans avoir la moindre ligne de code à changer, au niveau business

Mais dans tous les cas, si on a choisit de se servir de Qt dans un module je pense quíl faut jouer le jeu.

Comme tu l'as écrit, il faut faire le choix au niveau du module.

Qu'un module ait une dépendance forte vis à vis de Qt (ou de n'importe quelle autre bibliothèque), ca se comprend et ca se justifie pleinement, mais, de là à accepter que tous les modules aient ce genre de dépendance y compris lorsque cela ne se justifie pas forcément, il y a de la marge

(apres j'avouerais que jai jamais rencontre un cas ou le Q supplementaire justifiait son emploi par rapport a la STL, mais ca me gene pas de voir un tel code)

Comprends bien que ce n'est pas le recours à une QList ou à une QStringList (ni à n'importe quel autre QMachinChose) qui me dérange, car je n'ai strictement aucun problème de conscience à les utiliser...

Ce qui me dérange le plus, c'est de les utiliser, en posant une dépendance forte vis à vis de Qt quand (et j'insiste sur le quand ) la dépendance ne se justifie pas par ailleurs

Enfin pour les stagiaires, uiui on est daccord, c'est pas non plus le monde des bisounours

En effet

Pourtant Qt n'est pas que de l'IHM.
Ce que tu dit est pareil pour n'importe quel framework. Remplace Qt par Boost dans ton paragraphe par exemple et se sera tout aussi vrai;p

Juste pour dire, que choisir un framework pour l'exploiter au maximum as aussi beaucoup d'avantage. Voir peut être plus que moins (ou pas ).

Par exemple (comme on parle de Qt) pour un de mes dernier projets on as décidé de baser l'application entièrement sur Qt. En l'exploitant au maximum j'ai :
* des threads avec eventloop
* des communications inter thread par event ou signal/slot
* des manipulations d'objet par des algo concurrent
* des states machines
* des plugins
* un cache
* des QVariant(sorte de void* typé)
* des meta data.
* un peux de 3D
* de l'affichage d'image char, short, float, complexe, bayer,...
* des smart pointeurs et des lambda dans des QVariant.
* de l'IHM

Pour faire fonctionner tout cela, j'ai dû utiliser 3 mutex au maximum pour optimiser 2-3 petites choses. Et au finale, la partie GUI de Qt n'est qu'une petite partie de l'application. Au contraire Qt à permis une architecture multi thread très robuste et très facilement extensible par plugin.

Oh je n'en ai pas qu'après Qt sur ce coup là, mais sur toute bibliothèque qui souffre, classiquement, du syndrome du NIH, et elles sont nombreuses.

J'aurais réagis de la meme manière concernant la VCL de borland, ou la WCF de microsoft, je te rassure

Personnellement, j'aime vraiment l'idée de laisser le business (qui est quand meme sans doute la chose qui change le moins, meme si cela évolue pas mal au fil du temps) le plus indépendant possible, "simplement" parce que l'on ne sait pas de quoi demain sera fait (par exemple, le fournisseur d'une bibliothèque quelconque peut très bien changer sa politique commerciale, ce qui pourrait pousser à l'abandon de cette bibliothèque au profit d'un "concurrent" )

Le projet sur lequel je travaille souffre certes de nombreux problèmes, mais, s'il y a une chose que je trouve géniale dessus, c'est que l'ensemble a été correctement modularisé, au point qu'il y a :

• des parties business qui ne dépendent que de la STL
• une autre qui dépend d'OHCIpour la connexion à la BDD
• d'autres qui dépendent de la partie non IHM de Qt et
• d'autres enfin qui dépendent carrément de la partie IHM de Qt
• Tous les tests unitaires qui dépendent de cppunit (et qui couvre l'ensemble de ce qui n'est pas du niveau de l'IHM)

Ceci dit, j'admets sans aucun problème que la décision de tout baser sur une bibliothèque comme Qt puisse se justifier pleinement da,s certaines circonstances,tant il est vrai que Qt ne fait pas que de l'IHM...

Mais, il faut rester franc et se dire qu'il faudra assumer ce genre de décision sur le long terme (ou, du moins, sur toute la durée de vie du projet), et que c'est un choix qui interdit de facto tout retour en arrière

Bien sur, Qt compte parmi les bibliothèques pour lesquelles nous aurons sans doute le moins de raisons à long terme de décider de "changer de crèmerie", mais, si "d'aventure", cela devait arriver, tu n'aurais que deux solutions possibles : soit te plier au "bon vouloir" des fournisseurs de Qt, soit jeter à la poubelle tout ce que tu as fait jusqu'à présent

Mais bon, on s'écarte sérieusement du sujet, là... Je vais envisager de déplacer ce genre de considération dans une discussion à part (mais pas ce soir, trop fatigué )

[yan]

Oh je n'en ai pas qu'après Qt sur ce coup là, mais sur toute bibliothèque qui souffre, classiquement, du syndrome du NIH, et elles sont nombreuses.

Je sais bien .
Je voulais juste illustrer pourquoi la sélection d'un framework et l'exploiter au maximum a aussi des avantages.

[singman]

La seconde raison est une question d'expressivité. Lorsque l'on rencontre un for dans le code, on ne peut pas savoir ce que va faire ce code. Il est nécessaire de lire le contenu du bloc et cela peut devenir très complexe, surtout si on appelle beaucoup de fonctions et que l'on manipule de nombreux objets dans ce bloc.

Alors là, je pense qu'on touche le fond...
Déjà l'idée d'interdire le for() est stupide (oui, stupide mais je pense encore plus).
Mais vouloir faire croire qu'utiliser la STL rend le code plus expressif ! Non mais je dois rêver, vous avez apprit le C comment ? La compréhension de ce que fait un code n'est JAMAIS dans le code lui même, quelque soit le langage, mais dans la manière dont il est écrit.
Il faut commenter, expliquer, éviter les astuces personnelles, se conformer au standard de l'entreprise pour laquelle on développe.

Ce sondage est simplement un non-sense. Et vous êtes prof ?

[JolyLoic]

Puisque je suis la personne citée, je vais répondre, même si ce n'est pas moi qui ait ouvert cette discussion et que j'ai l'impression qu'une partie des reproches lui est adressée.

Alors là, je pense qu'on touche le fond...
Déjà l'idée d'interdire le for() est stupide (oui, stupide mais je pense encore plus).

Encore une fois, l'idée n'a jamais pour moi été d'interdire, mais de déconseiller, et a contrario de conseiller les alternatives.

Mais vouloir faire croire qu'utiliser la STL rend le code plus expressif !

Je le dis et le maintiens. Et je vais donner quelques exemples, avec des algorithmes simples (c'est à dire qu'avec des algorithmes plus complexes, l'intérêt est encore plus grand).

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
void fctFor1(vector<double> const &notes)
{
	int nombreElèvesPassant = 0;
	for (size_t i = 0 ; i<notes.size() ; ++i)
	{
		if (notes[i] >= 10)
		{
			nombreElèvesPassant++;
		}
	}
	cout << "Elèves passant : " << nombreElèvesPassant << endl;
}
 
void fctStl1(vector<double> const &notes)
{
	int nombreElèvesPassant = count_if(notes.begin(), notes.end(), [](double d){return d>=10;});
	cout << "Elèves passant : " << nombreElèvesPassant << endl;
}

Ici, j'ai hésité à supprimer la variable intermédiaire. Dans du vrai code, elle disparaîtrait probablement. Le code STL permet immédiatement de savoir que l'on va compter. En plus, on veut une valeur, on appelle une fonction, c'est direct. J'aurais aimé pouvoir le simplifier en count_if(notes, [](d){return d>=10;});, mais le C++ ne permet pas encore ça.
Le code à base de for ne s'écrit plus comme une fonction, mais comme un bout de code modifiant une variable locale. On remplace une fonction pure par du code statefull, ce qui est généralement moins clair.

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
void fctFor2(vector<double> notes)
{
	display(notes);
	for (size_t i = 0 ; i<notes.size() ; ++i)
	{
		if (notes[i] < 0)
		{
			notes[i] = 0;
		}
	}
	display(notes);
}
 
void fctStl2(vector<double> notes)
{
	display(notes);
	replace_if(notes.begin(), notes.end(), [](double d){return d<0;}, 0);
	display(notes);
}

Mêmes principe. Dans du vrai code, j'écrirais probablement un commentaire avant le for, je n'en verrai pas l'utilisé avant le replace_if : il ne ferait que paraphraser le 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
23
24
void fctFor3(vector<double> const &notes)
{
	for (size_t i = 0 ; i<notes.size() ; ++i)
	{
		if (notes[i] < 10)
		{
			cout << "Je n'ai pas une classe de génies" << endl;
			return;
		}
	}
	cout << "J'ai une classe de génies" << endl;
}
 
void fctStl3(vector<double> const &notes)
{
	if (all_of(notes.begin(), notes.end() , [](double d){return d>=10;}))
	{
		cout << "J'ai une classe de génies" << endl;
	}
	else
	{
		cout << "Je n'ai pas une classe de génies" << endl;
	}
}

Non mais je dois rêver, vous avez apprit le C comment ?

Je n'ai jamais vraiment appris le C, mais je ne vois pas le rapport.

La compréhension de ce que fait un code n'est JAMAIS dans le code lui même, quelque soit le langage, mais dans la manière dont il est écrit.
Il faut commenter, expliquer, éviter les astuces personnelles, se conformer au standard de l'entreprise pour laquelle on développe.

Je ne suis pas entièrement d'accord avec la première partie de la phrase. Par exemple les commentaires décrivent non pas ce que fait le code, mais ce que la personne l'ayant écrit croyait qu'il faisait. Quand il s'agit d'utiliser du code, les commentaires suffisent généralement. Quand il s'agit de le déboguer ou de le faire évoluer, ils ne sont plus suffisants, et un code écrit clairement devient alors un atout majeur.

Mais surtout pour moi les commentaires les plus intéressants sont ceux qui sont donnés non pas par // ou /* */ mais par des noms de variables ou de fonctions expressifs. Et on rejoint un des deux reproches que je fais à for : Il est tellement générique qu'il n'aide pas à comprendre dans quel objectif une boucle a été écrite (le deuxième étant qu'il est tellement générique qu'il est facile de se planter dans son utilisation). On peut certes mettre un commentaire avant le for, mais ça revient pour moi à utiliser des variables nommées v1, v2, v3 et à commenter à côté de la déclaration que v1 est le prix unitaire, v2 la quantité et v3 l'âge du vendeur.

Ce sondage est simplement un non-sense. Et vous êtes prof ?

Je suis avant tout développeur. Je donne un enseignement mais ce n'est pas mon activité principale. Par contre, j'ai pu constater grâce à ça qu'avant que l'entraînement et l'habitude ne viennent contrecarrer ça, les débutants se trompent régulièrement dans l'écriture d'une boucle for. Ce qui est en soi signe que c'est un des éléments complexes du langage, et donc une source de bugs, même dans du vrai code.

[Bousk]

Je me demandais, est-il possible avec une telle écriture (for range loop, foreach, ...) de réaliser un break et sortir de la boucle plus tôt ?
Bien que je suppose qu'il s'agisse d'une mauvaise pratique.