Ça veut dire quoi âgé ? Quelqu'un qui a la tremblote ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ça veut dire quoi âgé ? Quelqu'un qui a la tremblote ?
Ahem...Envoyé par fcharton
Les papis, si vous écrivez des trucs comme ça, comment voulez-vous qu'on vous prenne au sérieux (d'un point de vue strictement technique s'entend) aussi?
Je ne suis plus très jeune moi non plus, mais si j'ai beaucoup à apprendre des séniors, sur certaines choses, certains jeunes m'impressionnent. Un ami ici, âgé de 26 ans, est capable d'optimiser un code c++ en partant du diagramme de classes jusqu'à l'optimisation des assembleurs (en utilisant les GPU et pleins de trucs auxquels je ne connais rien, style les chipsets de certaines cartes mères permettent tels types d'optimisations etc.), et de façon à ce que ça fonctionne sur n'importe quelle architecture physique (proc & carte graphique). En revanche, il est très mauvais dans le versionning, la vision globale des projets, les besoins utilisateurs, etc, choses que des dev plus âgés appréhendent mieux.
Donc oui, nous sommes complémentaires, comme dans n'importe quel métier. Et si un jour les capitalistes français comprennent cela, alors ils embaucheront les deux types de profils, en laissant un peu de répit aux plus productifs pour du transfert de connaissance et un peu d'encadrement. C'est le gros problème de la France, les managers veulent tellement de productivité qu'il n'y a plus de place pour tout ce qui fait la vie d'une entreprise et assure sa pérennité.
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
Quel était le problème avec cette phrase?
C'est un constat, sur les langages que je pratique (C++, donc compilé, mais aussi Delphi), il y a presque toujours une corrélation entre la densité du code et la vitesse d'exécution finale.
Il y a bien sur des raisons techniques à cela: un code compact c'est presque toujours des boucles "profondes" courtes, moins d'indirections, autant de choses qui vont plus vite. Mais la principale raison est qu'en général, plus un code est dense, plus il est "pensé". Le code avec des bouts partouts et des tas de petits machins dans de petites cases, c'est généralement de la spec transcrite, souvent bêtement.
'fin bon, c'est juste un constat de vieux, quoi...
Par ailleurs, l'optimisation d'un code, ce n'est presque jamais l'optimisation des instructions, GPU et autres machines techniques, mais presque toujours celle des algos, et des structures de données. C'est là qu'on gagne les ordres de grandeurs, ce qui est la raison d'être de l'optimisation.
Francois
C'est en grande partie inexact, voire partiellement faux. D'une part un new, en C et en C++, n'initialise rien du tout. Ce n'est pas écrit dans la norme, et si certains compilateur avec certaines options le font (comme par exemple visual studio en mode debug), ce n'est jamais le cas en mode optimisé.
D'autre part, les récentes évolutions du c++ permettent, dans certains cas, d'éviter des allocations lors de new (voir par exemple le COW de Qt ou la move semantic en c++11). Mais c'est sûr, c'est récent donc c'est mal.
3 fois plus? D'où sort ce chiffre?
Un peu de rigueur est effectivement nécessaire si l'on choisi d'utiliser les exceptions. Mais c'est le même type de rigueur qui est nécessaire à la gestion de la mémoire en C à coup de malloc, realloc et free, ou des pointeurs, etc. Juste un outil supplémentaire, qui, s'il est bien utilisé, peut être très puissant. On peut choisir de ne pas le faire (comme google par ex.), mais il est dans la boite à outil et ce serait une erreur de l'ignorer.
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
C'est peut-être plus un problème de la définition qu'on donne au mot "densité".
Prenons un exemple concret, et du code que tout le monde en c++ connait: la STL et boost. Ce sont certainement deux exemples de code les plus "pensé" et optimisé. Si tu regardes bien comment sont implémentées ces bibliothèques:
- il n'y a qu'une instruction par ligne. Qu'une variable définie à la fois. Chaque opération est divisée de façon à ce que chaque ligne n'effectue qu'une seule opération. Par exemple, a = b + c + d; sera écrit en 2 lignes.
- chaque fonction n'effectue qu'une et une seule opération. Les fonctions sont donc très courtes, mais il y en a beaucoup.
- c'est du code qui est presque totalement templatisé, or il n'y a pas plus verbeux que les templates.
Si tu regardes ensuite le code de logiciels open source, le code est rempli de commentaires et de références. Les noms de variables et de fonctions sont longs et explicites.
Et effectivement, comme tu le dis:En réalité, les gros gains se font dans les algos et les structures, ensuite on va chercher les derniers pourcentages dans le bas niveau, et les dernières décimales dans le matériel. Bon à part quelques cas particuliers où tu peux gagner 60% juste en ajoutant une directive opemMP au bon endroit ou en utilisant une lib de calcul GPU. Mais je ne vois vraiment pas ce que la "densité du code" vient faire là-dedans.
D'ailleurs, aujourd'hui la mode veut que l'on préfère un
à
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9int b = 0; if ( a==0 ) { b = 1; } else { b = 2; }Ces deux codes génèrent le même asm une fois compilé, et pourtant aujourd'hui le premier est considéré comme "meilleur". Et il y a des raisons à cela. Ok c'est une mode, un tendance, appelez ça comme vous voulez, mais elle est fondée. Demain elle sera peut-être considérée comme obsolète, de la même façon que demain la théorie de la relativité sera peut-être infirmée, mais en attendant, ce sont des tendances issues de débats et de discussions. Et dans ces débats, les "vieux" développeurs ont une importance particulière et un poids important grâce à leur recul.
Code : Sélectionner tout - Visualiser dans une fenêtre à part int b = ( a==0 ) ? 1 : 2;
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
Effectivement, si tu penses aux retours chariots et aux blancs, ce n'est pas ce que je voulais dire.
Pour moi, un code dense c'est un code dans lequel on a progressivement éliminé le superflu, les appels redondants, les initialisations inutiles, les "sous fonctions" qui ne sont appelées qu'en un endroit, les sous classes que l'on avait crues utiles lors de la conception et qui se sont révélées superflues. Les paramètres de fonction 'au cas où', les fonctions membres gardées pour faire joli, les échafaudages divers qu'on a mis lors du débugage, et laissés en place.
C'est aussi un code où l'on évite les commentaires idiots : par exemple, des choses comme
C'est aussi un code qui a juste la complexité suffisante pour résoudre le problème et gérer les extensions prévisibles (pas un machin qui fait des additions en grands nombres "au cas où")
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Je ne sais plus qui disait que la perfection ce n'est pas quand on ne peut plus rien ajouter, mais quand on ne peut plus rien retirer. Je crois que ça s'applique parfaitement au code (et pour cette raison j'aurais du mal à considérer la STL ou Boost comme du code exemplaire, on se traine quand même depuis des décennies le module "valarray", qui est fourni avec une étiquette disant : ne pas l'utiliser).
Ca ne me parait pas de bons exemples. D'abord c'est de la librairie, faite pour être utilisée mais assez difficile à lire. Ensuite, c'est du code générique, fait pour passer partout, parfois aux dépens de l'efficacité, et surtout de la lisibilité.
Je ne sais pas toi, mais si on me donnait à maintenir un programme écrit dans le style de la STL, je n'aimerais pas trop...
Ca dépend des logiciels, ça, mais ça indique davantage l'époque où ces logiciels ont été écrits (et les bonnes pratiques du moment) que la qualité du résultat (et ce n'est pas parce que c'est open source que c'est bien fait...)
En général, le bas niveau, c'est le travail de ton compilateur. Si tu lui donnes du code assez simple, il fera les choses mieux que toi. C'est d'ailleurs la raison du style STL : le code simple (une instruction par ligne) a tendance à mieux s'optimiser).
La seule raison que je vois, c'est que le premier code fera moins peur à un développeur junior, qui aura l'impression en le lisant d'avoir compris 9 lignes de code (yesss!).
Personnellement, je préfère la seconde, tu l'auras compris. Cette ligne n'a aucune valeur ajoutée: elle initialise b à une valeur qui dépend d'une condition, et c'est une situation tellement banale que les concepteurs du langages lui ont consacré une instruction. On est en droit d'espérer que tout développeur connait la syntaxe (a?b:c).
C'est un truc qui m'a toujours épaté, ça. D'un côté, on s'entend répéter qu'il ne faut pas de fonctions longues, parce que c'est dur à lire et à comprendre, on insiste sur la nécessité d'utiliser, partout où l'on peut des fonctions de librairies (pas toujours explicites, eg le "remove" qui n'enlève rien dans la STL), mais il faudrait ne pas utiliser les raccourcis syntaxiques du langage lui même...
On retrouve la même chose avec l'optimisation, d'ailleurs. Ce sont les mêmes développeurs qui, au prétexte que l'optimisation prématurée c'est mal, insistent pour ne jamais faire une recherche dichotomique, qui veulent absolument utiliser une librairie mathématique haut de gamme dès qu'on a besoin d'une fonction trigonométrique, ou d'un nombre au hasard.
Francois
Tu as vu ça où, un "new" en C ???
Ce n'est peut-être pas le cas - je sais pas, je connais pas - en C++, mais ça l'était en Java... Et dans la plupart des langages OO..
Personne ne dit ça.... Simplement le C++ s'est mis à être massivemnt utilisé vers la fin des années 90... Attendre 2011 pour faire quelque chose, ça laisse entre 12 et 14 ans d'applis...
Il te faut bien un pointeur vers next et un vers previous, non ???
Si donc tu dois stocker un entier ou un pointeur, tu triples la taille du stockage...
@r0d:
Ce n'est pas une "mode", c'est un retour vers ce qui se faisait dans l'industrie..
@François::
non, moi j'ai toujours préféré la première vérsion. Pour une bonne raison, c'est que c'est lisible, facilement compréhensible par un mec qui a fait un autre langage (Fortran ou Pascal au hasard) .
J'ai en général horreur des signes cabailistiques, même si ils sont autorisés..
De même, les "i++" par exemple , je ne les met que dans les boucles.. Sinon je met "i = i +1".. Pour le compilo c'est kif-kif, et c'est plus lisible.. Quant aux "++i" ils sont tellement à déconseiller qu'ils ne devraient même pas exister...
"ce qui se conçoit bien s'énonce clairement"...
Si c'est un raccourci et non pas une instruction à part entière, il n'y a aucune raison de mettre le raccourci... Surtout quand c'est un signe qui fait se poser des questions (le "?" est un excellent exemple.. N'importe quel programmeur venant d'un autre langage se grattera la tête un bon moment pour savoir ce que c'est que ce truc... En particulier si il fait du dépannage ..., alors que le if..else.. est tellement évident)
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Boost est un bac a sable pour experimenter des trucs [par Stroustrup], et ne devrait probablement pas etre utilise en production car elle ne respecte pas la compatibilte arriere -- c'est a dire qu'un simple update de la librairie peut rendre un programme non fonctionnel, car l'API Boost a change entre les deux versions.
extrait de la FAQ boost :
Mais en dehors de ca, tu as raison.How can the Boost libraries be used successfully for important projects? Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible. Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems. Individual bug fixes can always be obtained from the boost repository.
"Le code de logiciels open source", ca ne veut rien dire. Je peux t'en sortir des dizaines avec des fichiers qui se nomment 1.c, 2.c, etc... et dont le contenu est a la hauteur du nommage du fichier... Et ce fut le cas pendant des annees, "pour que le code ne puisse pas etre copie par n'importe qui" disait-on. Ce n'est pas parce qu'aujourd'hui certains codes open-source sont bien ecrits et clairs qu'ils le sont tous.Si tu regardes ensuite le code de logiciels open source, le code est rempli de commentaires et de références. Les noms de variables et de fonctions sont longs et explicites.
Pas forcement le meme code ASM non (gcc 4.1.2 sans options de compilation). Par contre, il est evident que le premier code est beaucoup plus lisible que le second.Ces deux codes génèrent le même asm une fois compilé, et pourtant aujourd'hui le premier est considéré comme "meilleur".
Moi non plus, effectivement.
Non, mais c'est parce que c'est open source que l'on a accès au code. Parce que si je te parle d'un code auquel personne n'a accès, alors je peux te raconter n'importe quoi. Si je te parle du code de Firefox ou de libreoffice, tout le monde peut aller vérifier. Et de plus, en corolaire, j'ai eu l'occasion de lire beaucoup plus de code open source que de code propriétaire; donc en parlant de code open source, je limite mes affirmations à quelque chose que je connais bien.
Effectivement, mais parfois quelques cycles peuvent faire la différence, et là il faut aller sous le capot. C'est extrêmement rare d'avoir à en arriver là, j'en conviens, mais ça arrive.
Cette prose montre bien l'étendue de votre mauvaise foi. Les Sutter, Meyers et autres Alexandrescu n'ont rien compris et ne méritent pas votre attention. Tu ne cherches même pas à comprendre le pourquoi d'un résultat que tu le juges déjà, à l'aune de ta seule et donc légitime appréhension. ça ne me donne même pas envie de t'expliquer. Mais je vais le faire quand-même pour la discussion.
Tout d'abord, il faut comprendre que les deux codes concernés sont strictement équivalents une fois le code compilé. Donc on peut écarter les arguments de rapidité d'exécution, de compilation ou la taille de l'exécutable. Les différences ne se situent qu'au niveau de l'écriture, donc de la sémantique, de l'interprétation et de l'ingénierie (ou génie logiciel comme disent certains).
"Un programme doit être lu comme un texte", c'est une idée qui n'est pas nouvelle (cf. le langage pascal), et l'expérience a montré que c'était une bonne approche, car c'est du temps de gagné à chaque lecture de code; or le code est plus souvent lu qu'écrit. Un if/then/else est plus proche du langage humain qu'un "=(==)?:".
Il existe un principe en développement logiciel, qui s'appelle le SoC (Separation of Concern). C'est un principe, et en tant que tel, il est sensé résoudre plusieurs problèmes. Une des applications concrètes du SoC consiste à n'effectuer qu'une opération par ligne de code. L'opérateur ternaire ne respecte pas ce principe. Concrètement, du code qui respecte le SoC est plus facile à lire, à comprendre, à débugger, donc à maintenir. Un exemple concret: si tu met un point d'arrêt sur un opérateur ternaire, tu ne sauras pas si le compilateur est en train d'effectuer la comparaison ou l'affectation, et tu ne sauras pas si les valeurs de tes variables sont dans l'état N ou l'état N+1.
Cette discussion sur l'opérateur ternaire est récurrente, car bien qu'en soi c'est un détail ridicule, infime, dans le fond le problème que cette question pose est l'évolution des "best practices". Il est normal et sain qu'il y ait une opposition à ces évolutions, car sinon ça ne serait que des effets de modes sans fondements. Par exemple, moi je suis en opposition frontale à une tendance actuelle de classification des objets en sémantique de valeur et sémantique d'entité. En revanche, je suis un fervent partisan de S.O.L.I.D et de la programmation orientée service. D'autres sont d'avis différents, et chacun défend son point de vue, jusqu'à ce qu'un consensus apparaisse. Ou pas.
Le message que j'essaie de faire passer ici c'est que vous (françois, jean, mais bien d'autres) vous dites que les jeunes aujourd'hui font n'importe quoi et que l'évolution du développement logiciel ne fonctionne que par des modes sans fondements. Hé bien moi je vous dit que ce n'est pas du tout la réalité. Il suffit de regarder les débats concernant l'évolution du standard c++ pour se rendre compte que chacune de ces évolutions est largement débattue, réfléchie, murie, mise à l'épreuve à tous les niveaux. Le paradigme objet n'est pas apparu comme "un concept qui a de la gueule", mais pour répondre à des besoins concrets et dans le but de combler certaines lacunes des paradigmes existants.
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
oops, j'ai écris un peu vite
Tu as vu ça où, un "new" en C ???
Et non, car l'objet stocké dans le conteneur est généralement bien plus "gros" qu'un pointeur. C'est ce qui fait que bien souvent, un pointeur de plus par élément est totalement négligeable (si ta liste stocke des objets ou structures qui font chacun 1Ko par exemple, ton pointeur qui ne fait qu'1 octet est négligeable). Et lorsque le poids du pointeur n'est pas négligeable, c'est qu'on est dans une situation très particulière, donc rare.
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
faudra m'expliquer c'est quoi ce débat, qu'importe si la liste est simplement, doublement, triplement, etc. chainée, ce n'est qu'un détail, si on doit en arriver à optimiser à ce point c'est qu'on a déjà fait les classiques passes sur les algos et les données à traiter, donc c'est qu'on a besoin d'un très haut niveau d'optim, ce qui, désolé, ne se rencontre pas tous les 4 matins.
de plus ça relève d'un détail de fonctionnement et certainement pas du service que devra rendre le code, en ayant un code un minimum partitionné, on pourra remplacer aisément la liste chainés par un autre conteneur, et même encore par un conteneur maison ultra optimisé, c'est pas comme si on allait inventer de nouvelles fonctions sur les conteneurs, donc même interface et implémentations différentes.
vous arrivez à des situations ubuesques alors que la situations peut surement se résumer à un cas simple :
est ce que le petit jeune se trouve en face d'un ancien qui est resté avec les techniques d'il y a 25 ans sans jamais se mettre à jour, ou est ce qu'il a en face de lui un ancien qui a continué à s'intéresser à la technique et qui aura donc un oeil plus ou moins éclairé sur ce que le petit jeune connait et propose.
si la réponse de l'ancien est "c'est nouveau donc c'est nul" alors là je dirai qu'il faut mettre l'ancien au placard.
Lorsqu'on parle d'asm généré, on parle forcément de compilation avec optimisation, sinon ça n'a pas plus de sens que de parler de rapidité d'exécution en mode debug.
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
Heu... pardon je vais être lourd, et en plus hors sujet, mais tout ceci n'est pas exact.
-> i++ ne fait pas la même chose que i=i+1. Car quand tu fais mon_tableau[i++];, il te renvoie l'élément i et incrémente i après. Il doit donc conserver quelque part la valeur de i avant de l'incrémenter. Dans 99% des cas, c'est optimisé et au final il n'y a pas de différence, mais parfois le compilo ne peut pas optimiser ça.
-> en revanche ++i et i=i+1; sont équivalents. Et c'est la raison pour laquelle on préfère ++i à i++.
Tu devrais venir faire un tour sur le forum c++ de temps en temps
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
Bon à un moment faut aussi arrêter de rigoler: pour ma part, je travaille avec des professionnels et si je dois à chaque fois limiter ma prose au niveau de la Bibliothèque Rose pour ne pas choquer les incompétents, on n'est pas arrivé.
C'est pas toi qui refuse qu'on fasse deux chose différentes sur une même ligne? Pour ma part, je trouve ceci beaucoup plus sale et piégieux qu'un opérateur ternaire.
Ce sont des principes que je présente ici. Évidemment que parfois il n'est pas nécessaire ou pas utile de les respecter.
Bien sûr que je considère mon_tableau[i++] comme du mauvais code. C'était juste un exemple pour expliquer ce que fait l'opérateur ++ postfixé.C'est pas toi qui refuse qu'on fasse deux chose différentes sur une même ligne? Pour ma part, je trouve ceci beaucoup plus sale et piégieux qu'un opérateur ternaire.
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
Je comprends l'idée, et je suis d'accord sur le principe. Maintenant, la grande majorité des langages récents utilise une syntaxe voisine du C, avec des ++ pour l'incrémentation, et trouver l'explication de la syntaxe (a?b:c) me parait assez direct.
Je pars aussi un peu du principe que quelqu'un qui lit du code C++ connait la syntaxe du C++. Je veux dire, si tu ne connais pas cette syntaxe, tu as peu de chance de "deviner" les détails du langage, tout ce qui tourne aux fonctions membres, voire aux templates, par exemple, ou même ce que te garantit l'emploi d'un vector, or la fonction de bibliothèque find().
En fait je pense que je préfère la syntaxe ternaire parce qu'elle réduit l'espace écran qu'occupe le code, et que quand je lis du code, je préfère "voir" la structure que tourner les pages. Je pense aussi qu'elle est logique dans le sens ou elle "ne fait qu'une chose" (une conditionnelle si/sinon)
Tu te moques du monde, là... La première recommandation des C++ Coding Standard de Sutter et Alexandrescu, c'est précisément de ne pas trop s'exciter sur le style, du moment que cela reste lisible. En gros, n'importe quel développeur sérieux saura lire l'un ou l'autre.
Pour l'incrémentation sur les types de base, je ne sais pas ce qu'en dit Sutter, mais tu trouveras chez Koenig et Moo (au début) un petit commentaire expliquant que pour TOUS les types de base i++ et ++i produiront le même code dans tous les compilateurs récents (tant que tu n'affectes pas l'expression).
Quant au style un peu dense que j'affectionne, je l'ai trouvé chez Stroustrup.
Tu disais mauvaise foi?
Euh? et je suppose que == pour désigner la comparaison, la syntaxe de for( ; ; ), ou les règles d'héritage, de précédence, d'évaluation des expressions sont proches du langage humain.
Excuse moi, mais ce raisonnement est grotesque. Un programme est écrit dans un langage spécialisé, qui suit des règles précises, et que le lecteur DOIT connaître et bien maîtriser. Lui simplifier la tâche, c'est bien, mais partir du principe qu'il ne connait pas la syntaxe, ca me parait un peu exagéré.
Comme dans ...
ou
Code : Sélectionner tout - Visualiser dans une fenêtre à part for(int i=0;i<sz,i++) {}
(Sutter & Alexandrescu, op. cit. p 157)
Code : Sélectionner tout - Visualiser dans une fenêtre à part c.erase(c.remove(c.begin(),c.end(),value),c.end());
ou n'importe quelle fonction ayant des effets de bord, en fait...
En fait, comme je le disais plus haut, tu pourrais considérer que de tous ces exemples, l'opérateur ternaire est probablement un des plus SoC, au fond c'est un IF THEN ELSE comme on en a dans les langages informatiques depuis toujours.
Non, je crois que le problème qu'elle pose est la tendance de beaucoup de programmeurs à regarder le doigt, au lieu de la lune.
Et c'est ce qui explique que les "vieux" sourient quand un jeunot vient parler de bonnes pratiques, parce que la plupart du temps, ce qu'il en a retenu, c'est la règle d'indentation, le fait que "goto c'est mal" ou de jolis acronymes SFINAE et autres.
Le problème, c'est que les bonnes pratiques sont censées apporter des vraies réponses à des vraies questions, pas réguler des détails sans importance, "don't sweat the small stuff" comme disent S&A.
Ce n'est pas ce qu'on dit. Ce que j'essaie d'expliquer c'est qu'une bonne pratique qu'on n'a pas comprise, et surtout dont on à pas compris le problème qu'elle règle ne sert à peu près a rien.
Je pense aussi que l'idée que toute nouvelle norme, murie, débattue, réfléchie, est forcément une amélioration, est une vaste fumisterie. Il y a eu, dans l'histoire de l'informatique tout un tas de progrès dont on s'est rendu compte après coup qu'ils n'en étaient pas.
Enfin, l'objet, les normes, la syntaxe, les bibliothèques, les paradigmes, ne sont que des outils, on a tort d'en faire des religions ou des dogmes.
Pardon? On n'est pas dans l'optimisation là, mais dans les structures de base. Une liste ça ne fonctionne pas DU TOUT comme un tableau.
Par ailleurs, pour des tables d'index (c'est sans doute de cela qu'on parle, ici : un tableau contenant des pointeurs vers des données), un triplement de la mémoire nécessaire n'est pas non plus un détail...
Ca va être génial, je sens... Comme ça, on va pouvoir faire des insert dans le tableau, ou trier la liste et faire des recherches dichotomiques dedans.
C'est un principe de base de l'informatique: les conteneurs ne sont pas échangeables, parce qu'ils ont des fonctions, et surtout de performances, très différentes. Un tableau, ou une pile, est idéal pour un accès aléatoire, une liste pas. Une liste permet des insertions, un tableau pas. Trier un tableau est généralement une bonne idée si on a des recherches à faire, trier une liste, pas trop...
La STL fournit une SYNTAXE COMMUNE, mais elle ne rend pas les conteneurs interchangeables.
Francois
Dernière modification par Invité ; 08/05/2013 à 16h38.
Je crois que tu as mal lu
Contrairement à ce que toi et d'autres essayez de nous faire dire, nous ne disons pas ça..
Nous disons que :
parmi les différentes nouveautés appariassant tous les jours, bien peu sont réellement utiles et pérennes..
Ce qui n'est pas du tout la même chose...
Nous ne sommes pas "contre la modernité et le progrès", fô pas charrier... Nous sommes simplement dubitatifs quand on nous annonce avec fracas que "ce machin élimine les problèmes" , "cette façon de faire est obsolète", et autres joyeusetés du style "on ne peut pas faire un soft sans xxx"...
Or il se trouve que nos domaines sont truffés de ce genre d'annonces, et que les jeunes, par manque d'expérience et de recul, n'ont pas 'esprit critique pour comparer et évaluer..
D'une part ton pointeur ne fait pas 1 octet, mais 4 sur une machine 32 bits... Multiplié par 2 pour les 2.
Et lorsque le poids du pointeur n'est pas néglieable, c'est très courant.... Très souvent (en algo et maths en particulier) par exemple on fait des listes de pointeurs....
Tu veux que je te cite un exemple ??
Les algorithmes de sweep-line en maths. Pour traiter N points entiers, on stocke entre 6 et 10 à 12 N en mémoire...
Alors il me semble que ce n'est pas négligeable, une mémoire multiliée par 10.. Et si tu as 10 millions d'objets, tu passes juste d'une mémoire normale à devoir avoir une mémoire dédiée....
Et comme de plus on fait souvent tourner plusieurs softs en même temps, les problèmes de mémoire ne sont pas négligeables.
C'est justement une des plaies du gaspillage actuel de ressources....
Et toi tu devrais allez faire un tour sur le forum CHeu... pardon je vais être lourd, et en plus hors sujet, mais tout ceci n'est pas exact.
-> i++ ne fait pas la même chose que i=i+1. Car quand tu fais mon_tableau[i++];, il te renvoie l'élément i et incrémente i après. Il doit donc conserver quelque part la valeur de i avant de l'incrémenter. Dans 99% des cas, c'est optimisé et au final il n'y a pas de différence, mais parfois le compilo ne peut pas optimiser ça.
-> en revanche ++i et i=i+1; sont équivalents. Et c'est la raison pour laquelle on préfère ++i à i++.
Tu devrais venir faire un tour sur le forum c++ de temps en temps
++i incrémente avant... Si donc ce n'est pas un entier mais un pointeur, référencer ++p ou p++ n'ont strictement rien à voir...
Or la syntaxe , si on commence à l'utiliser, on ne distinguera plus comment l'utiliser pour des entiers et pas pour des pointeurs....
D'où gros problème
Déjà vu de nombreuses fois dans des codes....
tab[++i] ...
Tu as manqué le premier élément, et tu vas au delà du dernier
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
@françois: encore une fois, je parle de principes, ce ne sont pas des lois immuables ni des dogmes. Si le for ou le ERI (erase-remove idiom) ne respectent pas SoC, on ne va pas en faire une histoire. De même que la classe std::string est une horreur selon les standard du c++ moderne, mais ce n'est pas pour ça qu'on ne va pas l'utiliser. On peut d'ailleurs pinailler sur le fait que le ERI respecte SoC car il ne fait qu'une opération: supprimer un élément. Mais là n'est pas la question.
Comme je le disais, les évolutions surviennent en réponse à des problèmes précis. Le fait que les langages de développement sont de plus en plus conçus pour ressembler à des langages humains répond aux coûts de maintenance des logiciels. C'est peut-être une erreur, l'avenir le dira, mais ce n'est pas une mode sans fondement. Mais en attendant, un professionnel doit pouvoir déchiffrer n'importe quel code de son langage préféré, nous sommes d'accord, mais c'est tout de même mieux s'il peut le faire plus rapidement, non?
D'ailleurs, concernant l'opérateur ternaire, je ne suis pas entré dans les détails et il n'est en fait pas exactement identique au if/else, et dans certains cas il peut être utile. Mais c'est une longue histoire et les discussions à ce sujet sont légion sur le forum c++.
Et je ne m'excite pas sur le style, je ne dit pas qu'il faut bannir l'opérateur ternaire, je prend juste cet opérateur en exemple pour essayer de montrer que les consensus évoluent, et que je pense que c'est une bonne chose de s'en tenir informé. Après évidemment, parfois les consensus a tort, et on s'en rend compte ensuite. C'est ce qui fait que l'informatique est aussi une science. Mais il ne faut pas tout rejeter en bloc.
Par exemple, il y a environ 5 ans je crois, Microsoft a recruté de nombreux gourous du c++ pour bosser sur c#, dont H. Sutter pour s'occuper des threads. Beaucoup (dont moi) ont crié au scandale, à la trahison. Nombre des meilleurs spécialistes du c++ allaient vendre leur âme à microsoft en travaillant sur un langage "idiot proof", pâle copie du java, fermé, propriétaire. Le diable. Il s'avère que, quelques années plus tard, le C# se révèle être un langage extrêmement bien ficelé, et malgré ses nombreux désavantages, s'avère être un choix parfaitement adapté à beaucoup de situations.
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
Ok, dit comme ça, je ne peux qu'être d'accord. Mais c'est pas toujours facile de vous comprendre
Je te suis pasEt toi tu devrais allez faire un tour sur le forum C
++i incrémente avant... Si donc ce n'est pas un entier mais un pointeur, référencer ++p ou p++ n'ont strictement rien à voir...
Or la syntaxe , si on commence à l'utiliser, on ne distinguera plus comment l'utiliser pour des entiers et pas pour des pointeurs....
D'où gros problème
Déjà vu de nombreuses fois dans des codes....
tab[++i] ...
Tu as manqué le premier élément, et tu vas au delà du dernier
Es-tu d'accord que {tab[++i];} est équivalent à {i=i+1;tab[i];} ?
Es-tu d'accord que c'est vrai quel que soit le type des éléments contenus dans tab?
Es-tu d'accord que {tab[i++];} est équivalent à {tab[i];i=i+1;} ?
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
et? c'est du niveau du détail de comment le service est rendu et de l'implémentation, certainement pas du service en lui même.
et alors tu parles toi même de performance différente, certainement pas de but premier différent : stocker des données.
quoi ça soit map, vector ou list, tu pourras associer plus ou moins facilement un index à une donnée, qu'on a besoin de performance dépendra du contexte, ça me rappelle qqun qui n'utilisait exclusivement des char* à la place des string sous prétexte que c'est plus rapide, et ça même pour les fonctions utilitaires qui ne sont appelés qu'une seule fois dans toute la vie d'un programme.
et encore un cas très particulier pour essayer d'en tirer un enseignement général ...
je vais prendre un autre exemple, j'ai de 10 à 100 entiers à stocker, des fois de temps en temps je fais des insertions et des suppressions, alors vector ou list?
bah n'importe lequel, mes contraintes en temps et en place sont tellement insignifiantes que l'un ou l'autre n'aura pas de conséquences dramatique à l'exécution.
est ce que je peux dire que dans tous les cas ça sera vrai? bah non, par contre si j'ai suffisamment découpé mon code, je pourrai changer de conteneurs assez facilement et m'adapter à d'autres contraintes.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager