Faut-il bannir le for du C++ ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

27/04/2012, 15h10
Mewyn
Je ne comprends pas le sujet "La boucle for face aux algorithmes de la bibliothèque standard".

La boucle for utilisant les algorithmes de la STL éxiste déja
Code:

1 2 3 4 for(Element& e:lsElement) { e.doSomething() }
Avec: g++-4.6 -std=c++0x ça marche.
27/04/2012, 15h32
Klaim

Cette boucle n'utilise pas d'algorithm de la STL.
11/12/2012, 10h23
r0d

Citation:

Faut-il bannir le for du C++ ?

Posée ainsi la question n'a pas de sens. Les algos de la stl utilisent eux-même des boucles for et il n'est pas possible de faire autrement. Pour bannir les boucles for, il faudrait donc interdire des choses qui sont faites dans la lib standard, ce qui n'a pas de sens (hors nommages, et encore, il y a là aussi de quoi discuter AMHA).

Je formulerais la question différemment: "faut-il encourager l'utilisation de <algorithm>?" Et là, la question devient intéressante. Car s'il me parait évident que <algorithm> doit être maîtrisée par tout développeur c++, je ne suis plus persuadé qu'une utilisation abusive soit bénéfique.

note: Je n'ai pas vu, dans cette discussion, d'arguments sur l'optimisation de code. Sans parler d'asm, certaines optimisations sont impossibles sans boucle for.
12/12/2012, 07h53
JolyLoic

Je pense qu'il n'a jamais été question de bannir le for du langage, mais plus de bannir le for du code que l'on écrit. Et là, la question a de l'intérêt.

De la même manière d'ailleurs que l'on pourrait bannir le new et le delete du code que l'on écrit en C++ !
12/12/2012, 11h01
r0d

Citation:

Envoyé par JolyLoic

De la même manière d'ailleurs que l'on pourrait bannir le new et le delete du code que l'on écrit en C++ !

Mais pas de new => pas de conteneur d'objets polymorphes, n'est-ce pas?
12/12/2012, 11h48
camboui

Au delà du for, la question soulève un problème de liberté plus générale.
Faut-il interdire les fonctions héritées du C ?
Faut-il imposer l'usage de (ce &@#§%$! de) iostream ?
Faut-il imposer l'usage de std::string et bannir char [] ?
Faut-il interdir le premier paradigme, à savoir la prog procédurale ?
Faut-il imposer une manière de coder ? (celle du prof bien sûr)
Faut-il restreindre les libertés ?
Les profs sont souvent adèptes de la pensée unique...

Bon, je m'égare :aie:

Juste pour dire que cadrer un exercice est une excellente idée pédagogique, mais en faire un prétexte pour déclarer que ce cadre est "meilleur" ne garantira jamais la lisibilité d'un code. Et moins encore ses performances.

goto fait toujours partie du langage, mais ça fait au moins une décénie que je n'en ai plus vu. Toujours faire confiance à l'auto-censure ;)
12/12/2012, 11h56
r0d

Citation:

Envoyé par camboui

goto fait toujours partie du langage, mais ça fait au moins une décénie que je n'en ai plus vu. Toujours faire confiance à l'auto-censure ;)

Tu as bien de la chance, moi j'en vois régulièrement :'(
12/12/2012, 12h05
gbdivers

Oui, oui, oui, oui, oui, oui. Sauf quand c'est nécessaire. D'autres questions ?

Plus précisément, je pense être faillible et donc préfère privilégier ce qui facilite la sécurité, l'évolutivité, la maintenabilité, etc. sauf quand j'ai besoin explicitement de faire autrement.
En général, ce sont les débutants et ceux qui ne comprennent pas ces problématiques qui pensent perdre de la liberté. On le voit que sur le forum, beaucoup parmi les plus expérimentés usent et abusent de vector, string, RAII, etc.

Si je bosse avec quelqu'un qui me dit qu'il est sur de son code qui ne respecte pas tout ça, il a intérêt à avoir une très très forte crédibilité technique
12/12/2012, 13h12
koala01

Citation:

Au delà du for, la question soulève un problème de liberté plus générale.
Faut-il interdire les fonctions héritées du C ?

En terme de fiabilité du code, très clairement...

Citation:

Faut-il imposer l'usage de (ce &@#§%$! de) iostream ?

On a beaucoup trop vite fait de passer un %s au lieu d'un %d, voir d'oublier un argument (ou d'en mettre un de trop) avec les fonctions équivalentes en C, alors, oui, sans aucun doute

Citation:

Faut-il imposer l'usage de std::string et bannir char [] ?

Entre les risques de dépassement de capacité, ceux de fuite mémoire et ceux de double libération de mémoire, encore une fois, oui

Citation:

Faut-il interdir le premier paradigme, à savoir la prog procédurale ?

Autant que faire se peut, oui... Surtout si l'utilisation de ce paradigme te fait recourir à des pointeurs de fonctions ;)

Citation:

Faut-il imposer une manière de coder ? (celle du prof bien sûr)

Oui, pour autant que cette manière imposée poursuive (et atteigne) un objectif unique, clair et précis : celui d'obtenir un code facilement lisible et maintenable

Citation:

Faut-il restreindre les libertés ?

La liberté de l'un s'arrête où commence celle de l'autre.

Dans ce sens, il fait partie de ma liberté de n'avoir pas à réfléchir pendant cinq minutes à ce que peut bien vouloir faire une ligne de code, surtout si je dois travailler dessus.

Dés lors, oui, il est parfois bon de restreindre les libertés.

Mais, rassures toi, ce que tu appelles "contraintes", tu ne tarderas pas à les appeler "confort de développement" ;)

Citation:

Les profs sont souvent adèptes de la pensée unique...

Ca dépend lesquels, et la manière que tu peux avoir de démonter leur pensée pour leur faire comprendre qu'ils font fausse route ;)
12/12/2012, 15h28
Flob90

Citation:

Envoyé par r0d

Mais pas de new => pas de conteneur d'objets polymorphes, n'est-ce pas?

C'est la même question que pour for. Tu peux te passer d'écrire un seul delete facilement (RAII des smart ptr), tu peux te passer d'écrire un seul new (fonction de création des smart ptr).
12/12/2012, 15h33
gbdivers

Citation:

Envoyé par Flob90

C'est la même question que pour for. Tu peux te passer d'écrire un seul delete facilement (RAII des smart ptr), tu peux te passer d'écrire un seul new (fonction de création des smart ptr).

Petite remarque, il n'y a pas de make_unique (sauf erreur de ma part), donc il faut quand même faire un new pour utiliser unique_ptr :

Code:

unique_ptr<T> p(new T);
12/12/2012, 15h37
r0d

Ha ok, je vois.
L'idée serait donc: n'utiliser que des smart pointers (lorsqu'on ne peut pas utiliser la pile ou des références) et interdire les pointeurs nus.
Vous voulez donc nous obliger à perdre systématiquement des cycles à tous les niveaux même lorsque ce n'est pas nécessaire!! Vous voulez rajouter ++ à c++ (ça donne c#... désolé, humour nerd...)!!!
Bon, là je le dis en rigolant, mais je ne sais pas, ces idées d'interdire les fonctionnalités de base du langage ne me plaisent guère. Pourtant je ne suis pas conservateur, c'est juste que j'apprécie la liberté offerte par le langage, et cela me convient ainsi.
12/12/2012, 15h47
Flob90

Tu devrais lire le reste de la conversation, l'idée (comme l'a compris et reformulé Loic dans d'autre messages) c'est plutôt de se demander si "Ne pas utiliser de boucle for si une autre alternative existe" pourrait être une règle de style, de la même manière que "Ne pas utiliser de goto si une autre alternative existe" en est une.

Si la réponse est oui, alors ça reste une règle de style, pas une règle absolue.

@gbdivers: Je sais, mais c'était juste pour appuyer la comparaison des questions.
12/12/2012, 15h56
gbdivers

Je comprend sans problème ta position r0d. C'est une question de choix de priorités de chacun dans le développement de projets.

Mon expérience (limité au domaine de la recherche biomédicale, mais je pense que c'est pareil dans d'autres secteurs) me dit que l'on perd énormément de temps à développer (correction de bugs, code qui fait ce que l'on aimerait qu'il fasse), à maintenir (changement de matériel, d'OS), à faire évoluer (ajout de fonctionnalités).
De plus, l'approche bas niveau a de l'intérêt que sur une faible partie du code, le reste du temps, les performances des outils plus haut niveau (RAII, smart pointeurs, conteneurs, iostream, etc) sont largement suffisant.

Donc pour moi, mon objectif est surtout de gagner en sécurité, maintenabilité, évolutivité, quitte à perdre une fraction du temps de calcul.

Passer du temps à faire du HPC (CUDA, multithreads, calcul distribué) qui me fait passer mes temps de calcul de plusieurs semaines à quelques heures, ça m'intéresse. Faire du code bas niveau qui me fait passer de plusieurs heures de calculs à plusieurs heures de calcul moins quelques minutes, ça m'intéresse moins.
Si ce code fait perdre beaucoup de temps de développement, la balance penchera très fortement vers l'interdiction (par défaut, mais accepté si vraiment justifié) de ces fonctionnalités bas niveau.

Concernant la liberté, j'aime aussi ça. Mais je préfère user de cette liberté pour optimiser ce qui doit l'être, plutôt que passer du temps à corriger des bugs

@Flob90
je sais que tu sais, c'est pour les autres lecteurs
12/12/2012, 15h57
camboui

Citation:

Envoyé par JolyLoic

Je pense qu'il n'a jamais été question de bannir le for du langage, mais plus de bannir le for du code que l'on écrit.

Sans vouloir être pointilleux, le titre du sujet est sans équivoque: Faut-il bannir le for du C++ ?

Koala,
Perso j'évite l'amalgame des "obligations" et "interdictions" avec les conseils, suggestions, recommandations.
Par ailleurs, je vois mal quiconque refuser de maintenir le code d'un autre sous prétexte qu'il y a trop de pointeurs et pas assez de foncteurs. Il fait pas long feu dans la boîte... ;)

Ceci dit, ce n'est pas à moi qu'il faut prêcher, je suis converti :ccool:
Depuis que je connais ce forum j'use des containers, des string et des foncteurs (avec des problèmes de performance dans certains cas avec les string, mais bon...).
Je m'adonne aussi à la programmation générique. Là par contre, la lisibilité des templates pose question. Certains codages dans boost laissent perplexe...
Mais bon, mais bon, je me soigne et je progresse tant bien que mal :aie:
12/12/2012, 16h13
gbdivers

Pour le titre, c'est volontaire. Faut bien nourrir les trolls de temps en temps, sinon ils vont sur les discussions techniques :aie:
Tu peux remarqué que même moi, j'ai pas répondu "toujours interdire" au sondage

Citation:

Par ailleurs, je vois mal quiconque refuser de maintenir le code d'un autre sous prétexte qu'il y a trop de pointeurs et pas assez de foncteurs. Il fait pas long feu dans la boîte...

J'ai l'impression que ça arrive quand même très souvent. Pas pour refuser, mais pour jeter l'ancien code (cf "On jette l'ancien code, on fait vite, à l'arrache, ça prend deux jours, ça marche." dans une autre discussion)
En d'autres terme, maintenabilité et évolutivité = 0

Citation:

Perso j'évite l'amalgame des "obligations" et "interdictions" avec les conseils, suggestions, recommandations.

Dans l'absolue, oui. En pratique, on voit que si on dit "il vaut mieux éviter", plein de personnes continuent à le faire (regarde les questions récurrentes des débutants surle forum...) En interdisant, on diminue fortement le code mode "n'importe quoi", quitte à le faire quand même, après vérification, validation, réflexion, dodo, re-réflexion, vote unanime de l'ONU.

Pour la lisibilité des templates, ce n'est pas une fatalité, à lire : Le C++ expressif n° 3 : pourquoi les erreurs des templates posent des problèmes et qu'est-ce que vous pouvez faire pour ça ?
13/12/2012, 00h09
JolyLoic

Citation:

Envoyé par gbdivers

Petite remarque, il n'y a pas de make_unique (sauf erreur de ma part), donc il faut quand même faire un new pour utiliser unique_ptr :

Code:

unique_ptr<T> p(new T);

Non, il n'y a pas de make_unique, mais ça s'écrit en 1 ligne, et ça va probablement être ajouté dans un futur très proche, et une fois qu'on a "patché" la bibliothèques standard avec make_unique, plus besoin de new dans le code fonctionnel ;)

Citation:

Envoyé par r0d

Ha ok, je vois.
L'idée serait donc: n'utiliser que des smart pointers (lorsqu'on ne peut pas utiliser la pile ou des références) et interdire les pointeurs nus.

Pas tout à fait. Actuellement, un pointeur nu est légitime dans deux cas :
- Pour faire du lien avec le code legacy
- En tant qu'observateur d'une resource gérée par unique_ptr (comme weak_ptr avec shared_ptr), ou un autre mécanisme où la durée de vie de l'objet n'est en rien liée à la durée de vie du pointeur nu. C'est à dire pas de delete de ce pointeur nu.

Le premier usage est appelé à disparaître, mais pas le second (et j'aurais bien aimé que ce second usage porte un nom différent, mais j'ai du mal à convaincre. Si j'avais plus de temps, j'écrirais un papier là dessus).

Citation:

Envoyé par r0d

Vous voulez donc nous obliger à perdre systématiquement des cycles à tous les niveaux même lorsque ce n'est pas nécessaire!! Vous voulez rajouter ++ à c++ (ça donne c#... désolé, humour nerd...)!!!

Il n'y a pas de cycles ajoutés par unique_ptr...

Citation:

Envoyé par r0d

Bon, là je le dis en rigolant, mais je ne sais pas, ces idées d'interdire les fonctionnalités de base du langage ne me plaisent guère. Pourtant je ne suis pas conservateur, c'est juste que j'apprécie la liberté offerte par le langage, et cela me convient ainsi.

Encore une fois, pour moi, il s'agit dans cette discussion plus d'interdiction au sens règle de codage, sachant que la première règle de codage de toutes, c'est quand même que toute autre règle peut être ignorée dans les cas où c'est justifié.
13/12/2012, 10h20
germinolegrand

Si c'est pour de l'observation pure, pourquoi pas une référence plutôt qu'un pointeur ?
Par contre si c'est pour pouvoir sélectionner et éventuellement nullptr, là oui...

Citation:

Envoyé par JolyLoic

Il n'y a pas de cycles ajoutés par unique_ptr...

Alors là, si quelqu'un a 2 minutes, je ne serais pas contre quelques explications car je ne comprend pas comment ce serait possible, et je crois que j'ai beaucoup à apprendre (et comprendre) de ce côté-là.

Prenons par exemple l'implémentation de unique_ptr de vs2010. Prenons l’opérateur de déréférencement et les accesseurs au pointeur:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 typename tr1::add_reference<_Ty>::type operator*() const { // return reference to object return (*this->_Myptr); } pointer operator->() const { // return pointer to class object return (&**this); } pointer get() const { // return pointer to object return (this->_Myptr); }
On voit bien qu'à chaque fois, il y a au moins une indirection => quelques cycles.
A moins que ces indirections ne soient "effacées" à la compilation?

13/12/2012, 10h53
gbdivers

Citation:

Il n'y a pas de cycles ajoutés (par rapport à une pointeur nu) par unique_ptr...

Dans tous les cas, tu au moins une indirection avec un pointeur. Mais unique_ptr n'en ajoute pas d'autres

(sinon, c'est pas quelques cycles, mais plusieurs centaines de cycles si l'objet pointé n'est pas dans le cache mémoire, du fait de la latence de la RAM...)

Voir 40 message(s) de cette discussion en une page