Version imprimable
J’ai eu une discussion avec un collègue qui prétend que déclarer les variables ailleurs qu’en début de fonction en C++ (éventuellement au début d’un bloc) est une mauvaise pratique.
Cela réduirait la compressibilité du code et serait même incompatible avec certains compilateurs.
Qu’en pensez-vous ?
qu'il a gardé ses vieux réflexes de codeur C...Citation:
Envoyé par ginchen
:mouarf:
si le code est bien organisé, non, ca ne réduit pas la lisibilité... mais bon, la qualité, c'est un tout. il ne suffit pas de nommer les variables au bon endroit si on leur donne un nom pourri et qu'on ne les initialise pas d'un autre coté par exemple...
Regarde cette discussion :
http://www.developpez.net/forums/sho...d.php?t=215405
Notemment à partir du post 7...
On dirait.Citation:
Envoyé par toxcct
Le C++ permet de le faire, ce qui est bien pratique :) comparé au C, pas d'incompatibilité connue.Citation:
Cela réduirait la compressibilité du code et serait même incompatible avec certains compilateurs.
Bienvenu sur le forum www.developpez.net en tout cas :)
Je pense exactement l'inverse: définir des variables ailleurs qu'à l'endroit où on peut les initialiser de manière sensée alors qu'on pourrait le faire est une mauvaise pratique.Citation:
Envoyé par ginchen
Je ne comprends même pas l'argument. Ce que je comprends ne me semble avoir aucun rapport.Citation:
Cela réduirait la compressibilité du code
C'est autorisé en C++ depuis au moins 1984... je doute qu'il y ait des compilateurs qui ne le supporte pas. (Ce n'est pas possible en C90 mais bien en C99, c'est peut-être ce qui induit ton collègue en erreur?)Citation:
et serait même incompatible avec certains compilateurs.
Merci pour vos réponses, ça va dans le sens de mon opinion, mais devant la conviction de mon collègue, je préférais avoir d’autres avis.
Bonjour,
Déclarer ensemble toutes les variables dans la même zone en début de foncion améliore la lisibilité du code. J'aurais tendance à être 100% d'accord avec ce collégue, d'autant plus qu'il admet d'éventuelles déclarations en début de bloc. Il faut penser à ce que le code peut être partagé avec des personnes qui justement pratiquent de la sorte.Code:
2
3
D'ailleurs, Pascal (et delphi) imposent cette "bonne" pratique.
donc si je résume Graffito, t'es un Codeur C !? :aie:
S'il y a une différence de lisibilité (dans un sens ou dans l'autre), c'est que la fonction est trop grande.Citation:
Envoyé par Graffito
Mettre les définitions aux endroits où on peut faire l'initialisation est tout d'abord obligatoire pour certaines classes qui n'ont pas de constructeur par défaut.
Mettre les définitions aux endroits où on peut faire l'initialisation permet de mettre plus de variables const. Ce qui est une bonne chose.
Mettre les définitions aux endroits où on peut faire l'initialisation et retarder celle-ci au maximum, c'est garder les définitions proches des utilisations et préparer la découpe de la fonction quand elle aura grossit. On n'aura pas alors à chercher si une variable est utilisée dans le bloc qui précède et si c'est bien pour le même usage.
Bonjour,
Je suis un codeur C++ occasionel et un codeur Delphi régulier. Je participe parfois à la maintenance de code C++ et je suis personellement géné par des déclarations non regroupées.
Mais, j'ai aussi constaté que lors de debuging avec les créateurs du code que le fait de disséminer les variables arrivait à masquer des anomalies/problèmes que l'on aurait pu détecter plus facilement si les déclarations de variables avaient été regroupées.
Toutefois, je conçois que les avis puissent diverger sur le sujet et les arguments de Jean-Marc Bourguet sont parfaitement recevables.
En fait, la discussion révéle indirectement un des défauts de C et C++ : pas de fonction locale à l'intérieur d'une fonction.
Déclarer une variable appelle son constructeur, puis faire un assignement appelle son opérateur d'assignement.
Alors que si on l'initialise direct, on fait simplement un appel au constructeur.
De plus des types ne supportent pas l'assignement et nécessitent d'être construits avec des paramètres appropriés.
Bref déclarer en début de bloc, c'est uniquement possible pour les types de base.
Bonjour,
La position de la déclaration/initialisation n'impacte en rien le codage ou le fonctionnement (à part l'allocation mémoire qui peut se faire plus ou moins tôt).Citation:
Déclarer une variable appelle son constructeur, puis faire un assignement appelle son opérateur d'assignement.
Alors que si on l'initialise direct, on fait simplement un appel au constructeur.
De plus des types ne supportent pas l'assignement et nécessitent d'être construits avec des paramètres appropriés.
Bref déclarer en début de bloc, c'est uniquement possible pour les types de base.
Apparemment, tu sais pas ce qu'est un constructeur.Citation:
La position de la déclaration/initialisation n'impacte en rien le codage ou le fonctionnement (à part l'allocation mémoire qui peut se faire plus ou moins tôt).
La déclaration "anticipée" n'est possible qu'avec les données default-constructibles comme le dit loufoque. Détestant particulièrement les mutateurs publics et autres fonctions init(), j'interdis aussi régulièrement les constructeurs par défaut.
Je suis à 200% derrière Jean-Marc. Ses remarques sont des plus pertinentes.
Dans la catégorie refactorisation, ces fonctions trop longues j'en ai déjà vu de bons paquets. Et à chaque ajout de fonctionnalité/correction de bugs il y a des variables qui changent. Et quand on programme comme des cochons, et en plus que l'on utilise les déclarations en début de fonctions, on se retrouve donc avec des fonctions qui tiennent sur trois pages d'écran : une demi-page pour les variables, une et demi pour les traitements d'exception, et une pour le code effectif). Tu rajoutes à cela des variables qui ne sont plus utilisées -- pour cela les déclarations antiticipées c'est génial pour avoir des résidus qui polluent inutilement du code. Bref, c'est vite illisible, plus pénible à refactoriser, ...
Perso, je préfère les fonctions courtes dont le code effectif tient dans des demis pages d'écran (Mes sessions de vim ont des fenêtres splittées dans tous les sens). Avoir les variables construites à leur valeur finale dès la déclaration aide beaucoup à la compréhension des codes AMHA. Spécifier leur non-mutabilité rajoute encore de la précision à ce que l'on veut exprimer -- au fait, pourquoi l'italique Jean-Marc ?
Après j'ai la flemme d'aller chercher le Coding Standard de Sutter & Alexandrescu, je sais qu'ils conseillent la règle de la construction initialisante.
En principe si on code de façon "correcte", on n'a pas besoin de déclarer 36 000 variables ni objets.
Une méthode est censée faire une chose et une seule.
Et déclarer des objets/variables en début de méthode, je trouve que ça n'a aucun intérêt. On déclare et on utilise une variable dans un bloc dont on en a besoin, locale à celui-ci et point barre.
Ce n'est pas le fait de situer une variable ici ou là qui rend le code illisible mais une méthode qui fait à la fois la café, qui lance la machine à laver, va chercher les courses, lance une alerte s'il y a trop de vent ....
Salut,
Je dirais que le fait de déclarer les variables en début de fonction *peut* avoir, quand on débute, une coté "sécurisant" pour le programmeur:
Apres tout, s'il oublie le nom d'une variable, il n'a qu'à aller voir le début de la fonction, et il est sur de trouver la liste de toutes les variables déclarée...Mais... C'est sans doute un mauvais calcul à long terme.
D'un autre coté, avoir une variable déclarée, c'est pas mal, mais avoir une variable initialisée, c'est encore mieux;)
Or, si l'on garde le pli de délcarer toutes les variables en début de fonction, il risque d'y en avoir plusieurs dont on ne peut pas prévoir, dés ce moment là la valeur qu'il faudra leur donner pour les initialiser...
On *peut* donc envisager de leur donner des valeurs par défaut, mais cela impliquera que l'on doive à chaque fois vérifier (ou presque) que la variable a été modifiée/initialisiée avec une valeur utilisable avant de l'utiliser... et ca finira par faire une fonction perclue de tests ou de blocs try...catch.
De plus, imaginons simplement une classe qui contitendrait une std::list<untype> et une std::map<unautretype>, et que la fonction doive boucler, d'abord sur les éléments de la liste, puis sur les éléments de la map...
On se trouvera, si l'on veut déclarer les variables en début de fonction, dans l'obligation de déclarer un itérateur sur la liste, avec son nom propre, et un autre sur la map, avec son nom propre également (sous peine d'avoir une redéclaration de variable)...
Alors que le fait de déclarer les variables au moment où elles sont utiles permet d'utiliser, un code du genre de
qui peut s'avérer plus lisible et plus cohérent... it et chaine n'existant que dans la portée tres précise de la boucle dans laquelle il sont utilisés...Code:
2
3
4
5
6
7
8
9
10
11
12
Et, de fait, si l'on décide de placer ces deux boucles dans des fonctions séparées, on sera sur, en faisant un simple couper/coller des boucles de partir avec toutes les variables dont les boucles ont besoin ;)
Le C++ permet la déclaration ailleurs qu'avant la premiere instruction, introduisant un concept de "variable super locale" (à un bloc d'instructions), autant en profiter... les compilateurs actuels sont en mesure d'en tirer le meilleur parti ;)
Sans compter que le fait de déclarer une variable au moment de son utilisation limite quand meme fortement le risque... d'en oublier son nom non?
Je ne suis pas d'accord. Il est très simple d'éviter les variables non-utilisées, un compilateur bien réglé voire un peu parano les signale.Citation:
Tu rajoutes à cela des variables qui ne sont plus utilisées -- pour cela les déclarations anticipées c'est génial pour avoir des résidus qui polluent inutilement du code.
Dans l'absolu certes. Sauf quand on ne peut pas choisir le compilateur avec lequel on travaille.
Excuses moi, Duarna, mais, j'aimerais que tu aie l'honneteté intellectuelle de ne pas prendre une phrase completement sortie de son contexte comme base de dénégation.
Bien sur, il est tout à fait vrai que le réglage adéquat du compilateur permet de retrouver les variables inutilisées, et parfois meme les variables non initialisées...
Mais la phrase de luc que tu site prend un sens tout à fait différent si tu la laisse dans le contexte complet:
Bien sur, la déclaration anticipée ne représente "qu'une goutte d'eau" dans la somme des problèmes que l'on peut rencontrer (dont la plupart sont souvent liés plus à la "non initialisation" qu'à la non utilisation).Citation:
Et quand on programme comme des cochons, et en plus que l'on utilise les déclarations en début de fonctions, on se retrouve donc avec des fonctions qui tiennent sur trois pages d'écran : une demi-page pour les variables, une et demi pour les traitements d'exception, et une pour le code effectif). Tu rajoutes à cela des variables qui ne sont plus utilisées -- pour cela les déclarations antiticipées c'est génial pour avoir des résidus qui polluent inutilement du code. Bref, c'est vite illisible, plus pénible à refactoriser, ...
Mais le sens de l'intervention de luc est que, si tu rajoute cette goutte d'eau à une série d'autres comportement "à risque" (allant de la mauvaise indentation/mise en forme à une taille excessive pour l'affichage du code de la fonction en passant par du code trop alambiqué, à force de "raccourcis" offert par le langage ou l'ajout de possibilité/le débuggage), la difficulté avec laquelle tu t'y retrouveras dans le code est bien plus que la simple addition de toutes les (petites) difficultés que chaque comportement implique... mais plutot de l'ordre de l'exponentielle des différentes difficultés
Mais, là, on aborde plus le problème des "bonnes" habitudes de programmation que le simple problème d'une déclaration anticipée.
Ainsi, cette simple ligne
est, susceptible d'etre tout à fait valide si les types de retours correspondent aux type des arguments attendus par les différentes méthodes...Code:membre=methrode1(methode2(methode3(methode4(), methode5())));
Mais il n'empeche que, meme avec des noms de méthodes "auto-commentée" (AKA dont on retrouve l'action effectuée dans le nom) la ligne présentera une difficulté de lecture bien suppérieure au code
qui fournira pourtant un résutlat tout à fait identique, et pas forcément plus lent à l'exécution - avec, bien sur,les types et les noms de méthodes/variables cohérents.Code:
2
3
4
5
6
Je sais qu'il n'est pas forcément courent d'avoir besoin de 5 ou de 6 fonctions pour déterminer la valeur d'un seul élément... mais, en C, par exemple, un code du genre de
est tout à fait valide... (si du moins, je n'ai pas fait d'erreur de parentheses, car je ne l'ai pas retesté avant de l'écrire :oops:)Code:
2
3
4
5
6
Il n'empeche que, la première fois que j'ai croisé cette syntaxe (j'étais débutant en C) j'ai eu un certain mal à comprendre le sens des tests et j'ai du recompter plusieurs fois le nombre de parentheses présentes pour etre sur de en pas en oublier...
Un code du genre de
aurait eu le meme résultat, mais avec la lisibilité en plus..et le risque de mauvaise compréhension/d'erreur en moins...Code:
2
3
4
5
6
7
Et pourtant, en nombre de touches de clavier enfoncées (espaces et touche <ENTER> inclus) il n'y a qu'une différence, si j'ai bien compté, de trois touches :P
Ayant appris la dactylographie, et "tapant" plus ou moins 60 mots de 8 lettres à la minutes, le deuxième code m'aurait pris... moins d'une demi seconde en plus à écrire :P
Crois tu réellement qu'en cas d'erreur dans le premier code (une simple parenthese mal placée ou oubliée, par exemple) j'aurais mis moins d'une demi seconde pour repérer et corriger l'erreur :question:
Et, faut il rappeler qu'une parenthese fermante est le genre d'erreur - avec la faute d'orthographe dans un nom de fonction ou de variable - le plus facile à situer, à repérer et à corriger parce qu'apparaissant dés la compilation...
Mets l'un de ces codes dans une fonction de 100 lignes, rajoute quelques déclarations anticipées de variables (sans les définir au départ) ou oublie de tester si la fin du fichier a été atteinte avant d'effectuer une lecture et... amuse toi à retrouver l'erreur à l'exécution ;) :P
Bonjour
Je suis tout a fait d'accord avec toi koala .
Mais apres tout depend a quoi est destiné ton code si il tend a devenir de l'open source autant rendre son code claire precis commenté bien indenté afin que tout le monde puisse comprendre celui ci , mais a la limite si le code ne sera lu que par la personne l'ayant ecrit je dirai tant que cette personne si retrouve chacun voix midi a ca porte ;) .
Il n'a meme pas besoin de tendre à devenir open source...
Le premier lecteur du code que tu crées, c'est toi ;)...
Le problème c'est qu'il y a mille et une raisons qui peuvent faire que tu veuilles revenir sur ton code plus tard.
Et "plus tard", ca peut varier de quelques heures à plusieurs mois, voir plusieurs années (apres tout, pourquoi pas :question:)
Le problème, c'est que, ce qui te parrait peut etre limpide au moment où tu l'écris risque de te parraitre beaucoup plus nébuleux quand tu y reviens "plus tard" (et généralement d'autant plus nébuleux que ce "plus tard" est éloigné de la création, et c'est encore pis si tu "reprend" un code dont tu n'es pas l'auteur parce que tu es intégré au sein d'une équipe)
Des cinq gros conseils de "belle présentation du code" que voici
- une linge= une instruction ou une declaration
- indentation cohérente du code
- utilisation de noms de fonction/variable en rapport avec l'usage qui en est fait
- éviter les fonctions trop longues (+/- 50 linges max)
- insertion de commentaires cohérents et utiles pour les parties les plus denses
seuls les derniers peuvent demander un peu plus de temps que les autres (ben oui, leur mise en pratique peut demander une réflexion approfondie ;) )
Surtout, quand on vois les éditeurs actuels qui permettent de créer une identation de manière automatique...
Le temps "perdu" à la mise en pratique de ces conseils sera en fait regagné dans une proportion énorme par la suite (qu'il s'agisse du débuggage, alors que le code est encore limpide ou de la reprise du code plus tard)
Si, en plus, d'autres personnes doivent pouvoir etre en mesure de comprendre ce que tu as codé, le gain de temps s'éleve presque de manière exponentielle ;)
[EDIT] Ceci dit, il est vrai que chacun voit midi à sa porte... par contre, il n'y aura au final que tres peu d'application sur lesquelles tu ne seras pas tenté de revenir ;)
Je suis tout a fait d'accord avec toi c'est d'aillieurs la methode que je pratique sur les gros projets et cette methode est execelente mais encore faut il que tout le monde la suive dans un meme projet ^^ d'aillieur j'ai une question tu utilise un TAB de combien ??
Personnelement j'utilise un TAB de 4 mais apres je voudrait savoir ce que vous en pensez ??(trop grand trop court...)
Ca, c'est la responsabilité du gestionnaire/chef de projet/ de l'entreprise que de définir (éventuellement sur avis des collaborateurs) une "politique de codage" cohérente commune et de la faire appliquer...Citation:
Envoyé par spawntux
Et ce n'est pas une mince responsabilité ;):P:P
Généralement, j'utilise une indentation de quatre espaces, mais sous forme d'espaces, et non sous forme d'une "définition du TAB" :P (et une mise en forme du type ANSI parce que le le K&R, personnellement, je ne m'y fais pas :oops: - meme si je n'éprouve que peu de problèmes à la lecture d'un code formaté avec - mais simplement parce que je trouve plus clair d'avoir l'accolade ouvrante sur la meme colone que l'accolade fermante ;))Citation:
d'aillieur j'ai une question tu utilise un TAB de combien ??
Personnelement j'utilise un TAB de 4 mais apres je voudrait savoir ce que vous en pensez ??(trop grand trop court...)
L'avantage d'un nombre fixe d'espaces est, à mon sens, que cela évite les problèmes dus au fait que la tabulation peut etre réglée sur 4 espaces dans un éditeur et sur... 16 sur un autre, avec la perte de la mise en forme que représente le passage d'un éditeur à l'autre...
Mais, en COBOL, par exemple j'ai pris l'habitude, du coté de la data definition, d'alligner les types sur la première lettre et les noms correspondants sur la derniere, avec indentation du niveau -et donc, un espace "variable" entre le numéro du niveau et le type de la donnée et entre le type et le nom - "simplement" parce que c'était la mise en forme que le prof appréciait quand j'ai pris les cours (il faut aussi dire que le COBOL est limité en nombre de caractères par lignes, alors que C et C++ ne le sont pas ;) )
Mais ces détails font typiquement partie "des gouts et des couleurs" - si, du moins, ils n'entrent pas dans l'optique d'une conception en équipe - et ce ne sont donc que des avis strictement personnels, avec tout ce que cela implique ;)
Oui bas tu doit avoir a peu pres les meme gout que moi je trouve egalement que les accolades sur la meme colonne c'est plus explicite ^^ +1 pour l'histoire chef de projet mdr .
Scott Meyers préconise de déclarer les variables locales le plus tardivement possible. L'argumentaire est dans un des items de "Effective C++", Item 32 "Postpone variable definitions as long as possible".
Son argument principal est effectivement de ne pas avoir à payer le coût de la
construction d'objets appartenant à des branches de la fonctions qui ne seront pas exécutées.
L'apparente clarté d'initialiser toutes les variables en début de bloc ne vaut que pour les programmeurs chevronnés dans les langages ou cette pratique est imposée.
Pour ce qui est du nombre d'espaces, de la place des accolades etc. Il existe des 'beautifiers' qui se chargent très bien d'uniformiser les différentes pratiques de tout un chacun.
Je suis contre les déclarations anticipées de variables en C++, car il arrive souvent qu'une variable ne soit écrite qu'une seule fois. Dans ce cas, s'il est possible de ne la déclarer et l'initialiser qu'à ce moment-là, on peut alors la déclarer const.
D'un autre côté, si on regarde les conventions de codage éditées par Sun concernant le langage Java, il est conseillé de déclarer toutes les variables en début de bloc alors même que le langage ne l'impose nullement. J'ai toutefois du mal à laisser de côté mes habitudes aquises en C++. Je ne sais pas si déclarer une variable proche de son utilisation change véritablement quelque chose sur une méthode de +/- 50 lignes max. par rapport à l'initialisation en début de bloc. En revanche, pouvoir initialiser des variables/objets directement à leur finale, et pouvoir déclarer la plupart de ces variables avec le qualificatif const lorsque c'est approprié apporte un gain substanciel en terme de lisibilité du code.Citation:
Envoyé par Jan Rendek
Thierry
Si, ce sera potentiellement plus lent en C++0x.Citation:
Envoyé par koala01
Et je trouve cela beaucoup plus verbeux et plus sujets aux erreurs. Laisser faire l'inférence des types et la gestion des temporaires est plus pratique.
C++0x ne sera pas finalisé avant deux ans à peu pres, il est donc difficile de tirer des plans sur le comportement potentiel d'un tel code...Citation:
Envoyé par loufoque
Cependant, avec les classes qui vont bien (comprenant opérateurs d'affectation et autres, par exemple), la différence ne devrait pas etre tres flagrante
Le fait, justement, qu'un code soit plus verbeux est, pour autant que les noms de variables soient choisis de manière cohérente (et pas uniquemement val1...valn) est, à mon sens, bien moins sujet à erreur, car plus précis, que le fait de laisser faire les choses par le compilateur...
Si ralentissement il y a, il sera plutot minime, surtout quand on voit la vitesse atteinte par les processeurs actuels, mais l'écriture verbeuse du code permet, à mon sens, de rendre le code plus facilement compréhensible.
De plus, le passage par une variable temporaire peut s'avérer, en définitive dans certain cas particuliers bien plus rapide que l'utilisation de la fonction (je penses, entre autres, aux boucles pour lesquelles il est préférable d'utiliser une variable temporaire récupérant monobjet.size() plutot que d'appeler monobjet.size() à chaque fois dans la boucle... surtout si la la taille du contenur n'est pas modifiée à chaque itération...)
Je ne veux pas dire qu'il faut éviter l'utilisation des racourcis proposés par le langage, car il sont intéressants malgré tout, je dis juste qu'il doivent etre utilisés à bon escient, au meme titre que n'importe quelle autre technique...
*Si* amélioration de la vitesse d'exécution il y a, entre le code qui utilise directement l'appel des fonctions et celui qui utilise des variables temporaires, et si elle est sensible au point d'inciter à recourrir à cette possiblité, j'ai personnellement tendance à estimer que son utilisaiton devrait n'etre envisagée qu'en phase de test et d'optimisation, une fois que le reste a été testé et correctement implémenté, ou, si tu préfères, à un moment où il semble clair qu'il ne sera plus nécessaire de retourner modifier profondément le code - et en ajoutant, "par sécurité", les commentaires qui permettront de comprendre le but de la manoeuvre.
Cela n'est pas difficile du tout.Citation:
Envoyé par koala01
On sait que C++0x identifiera de manière différente les variables temporaires des variables non temporaires.
Certains compilateurs implémentent déjà cette possibilité.
On peut alors en particulier se permettre de déplacer les variables temporaires, alors qu'il est nécessaire de copier les autres.
La différence est flagrante pour tout objet référençant des ressources.
Il est surtout sujet à erreur dans le choix du type, provoquant problème de forwarding ou pire, une copie inutile.Citation:
Le fait, justement, qu'un code soit plus verbeux est, pour autant que les noms de variables soient choisis de manière cohérente (et pas uniquemement val1...valn) est, à mon sens, bien moins sujet à erreur, car plus précis, que le fait de laisser faire les choses par le compilateur...
Sans parler du fait que cela empêche certaines optimisations dans l'usage des références, qui sont probablement minimales en effet.
C'est sûr, la vitesse des processeurs nous permet d'utiliser du O(n) à la place de O(1).Citation:
Si ralentissement il y a, il sera plutot minime, surtout quand on voit la vitesse atteinte par les processeurs actuels, mais l'écriture verbeuse du code permet, à mon sens, de rendre le code plus facilement compréhensible.
D'ailleurs pourquoi ne pas rendre toutes les opérations exponentielles tant qu'on y est ?
Jamais un benchmark n'a réussi à démontrer une quelconque amélioration dans ce cas en utilisant un objet temporaire.Citation:
De plus, le passage par une variable temporaire peut s'avérer, en définitive dans certain cas particuliers bien plus rapide que l'utilisation de la fonction (je penses, entre autres, aux boucles pour lesquelles il est préférable d'utiliser une variable temporaire récupérant monobjet.size() plutot que d'appeler monobjet.size() à chaque fois dans la boucle... surtout si la la taille du contenur n'est pas modifiée à chaque itération...)
Pour la simple raison que std::vector<T>::size par exemple se limite à une fonction en ligne qui retourne une valeur.
L'utilisation d'une variable temporaire est uniquement utile si le traitement est relativement important pour éviter de faire plusieurs fois le même traitement.
De toutes manières, il n'y avait aucune répétition dans ton exemple originel.
Une fois que tu réalises que tu as oublié d'implémenter les sémantiques de mouvement tu veux dire ?Citation:
*Si* amélioration de la vitesse d'exécution il y a, entre le code qui utilise directement l'appel des fonctions et celui qui utilise des variables temporaires, et si elle est sensible au point d'inciter à recourrir à cette possiblité, j'ai personnellement tendance à estimer que son utilisaiton devrait n'etre envisagée qu'en phase de test et d'optimisation, une fois que le reste a été testé et correctement implémenté, ou, si tu préfères, à un moment où il semble clair qu'il ne sera plus nécessaire de retourner modifier profondément le code - et en ajoutant, "par sécurité", les commentaires qui permettront de comprendre le but de la manoeuvre.
Je n'ai pas trop suivi les discussions sur la move semantic, mais le compilateur n'est-il pas en droit de réécrire :Citation:
Envoyé par loufoque
ainsi :Code:
2
3
4
5
Il a le droit de le faire aujourd'hui, ce serait dommage s'il ne pouvait plus le faire à cause de la move semantic.Code:
2
3
Un T temporaire est convertible en T&&, un T non temporaire ne l'est pas mais est convertible en T&.
(Un T temporaire reste convertible en T const&)
Après les compilateurs ont peut-être le droit d'analyser le code pour voir si l'objet n'est en fait pas un temporaire car non utilisé ailleurs. Je n'en sais rien.
Mais a priori si ce genre de choses était autorisé, ça l'est toujours, sauf que le pseudo-temporaire ainsi obtenu n'est pas forcément convertible vers T&&.
Ok, on écrira alors
si effectivement on est dans un cas où ça peut jouer un rôle. Tient, je me demande comment ça interragit avec auto (qui règle le problème de la verbosité en autorisant l'inférence de type).Code:
2
3
4
Mais le fond de la remarque de koala01 tient toujours: il est des cas où est est plus clair d'introduire des variables que mettre des expressions imbriquées. Même les fans de la programmation fonctionnelle sont d'accord.
Il est extrèmement optimiste de penser avoir des compilateurs C++0X en production dans deux ans. On n'a toujours pas beaucoup de compilateurs C++98 conformes sur tout (je parie d'ailleurs qu'il y aura des compilateurs implementant les lvalue references avant export).
Le problème est différent en Java car toutes les variables de types non-scalaires sont allouées sur le tas.Citation:
Envoyé par mujigka
Ça doit rendre la NRVO impossible là par contre.
Et la déclaration n'appelle pas le constructeur en Java il me semble. Cela n'est fait qu'avec new.Citation:
Le problème est différent en Java car toutes les variables de types non-scalaires sont allouées sur le tas.
Comme avec des pointeurs en C++ quoi.
C'est exactement ce que j'entendais par là.Citation:
Envoyé par loufoque
Selon moi, si pour un meme algorithme, deux écritures sont possibles - l'une plus lente mais plus aisément compréhensible, l'autre plus rapide mais plus complexe à appréhender - il y a lieu d'utiliser la premiere tant que le code et ses implications sont susceptibles d'être modifiés en profondeur...
N'oublie pas qu'un projet peut s'étaler sur plusieurs mois, voire, sur plusieurs années, et que plusieurs personnes sont même susceptibles de "poser leurs yeux" sur la même portion de code.
Or, l'esprit humain est ainsi fait que ca demande un effort important - même s'il est inconscient - pour se remémorer ce qui est plus vieux qu'à peine quelques minutes... Je te laisse imaginer ce qu'il en est apres plusieurs mois...
L'optique la plus saine, pour éviter les pertes de temps inutiles, c'est de privilégier un code facile à "reprendre en main", tant qu'on n'est pas certain que le code ne devra pas etre retouché.
Il n'est en effet pas rare que, au fil du développement, on en vienne à modifier ce qui a été fait - par ajout d'un membre dans une classe, par exemple - et que cette modification nécessite de modifier une partie du code existant...
Mais comme la partie de code à modifier peut très bien avoir été écrite plusieurs mois plus tot - voire, par une autre personne de l'équipe - il est primordial que la personne qui sera chargée des modifications puisse prendre rapidement ses marques. Plus le code sera complexe, plus la personne aura du mal à récupérer ses marques...
Et certains algorithmes sont déjà suffisemment complexes pour ne pas les rendre encore plus difficiles à appréhender par l'utilisation d'une écriture - certes, qui fait gagner quelques nano secondes - mais qui va demander (beaucoup) plus de temps pour comprendre ce qui est fait...
Il faut bien comprendre que les optimisations d'écriture ne sont de nature qu'à faire gagner que quelques fréquences d'horloge... quelques nano seconde au vu des processeurs actuels.
Lorsque l'on testera les fonctions "petits bouts par petits bouts" la différence sera à ce point minime qu'on ne la remarqueras meme pas...
Par contre, ces optimisations d'écriture sont clairement de nature à faire passer plusieurs minutes, d'ici un mois ou deux, à se poser des questions du genre de "mais que fait ce test :question:" ou "mais que fait cette fonction qui demande trois autres fonctions en paramètres :question:". Et ca, c'est vraiment du temps perdu pour rien...
Maintenant - une fois que tous les "petits bouts" sont prets et sont rassemblés - si, en période finale de test, on se rend compte qu'une optimisation d'écriture permettra de gagner en performances - parce que les petits ruisseaux font les grands fleuve et que, justement, cette fonction est appelée de nombreuses fois, et principalement au sein de boucles - nécessité fait loi: l'écriture doit être optimisée.
Mais ca doit etre fait en tout dernier, juste avant de remettre l'application à celui qui l'a demandée ;)
Du moins, tel est mon avis, quitte à me faire traiter d'hérétique par certains :P
Je ne trouve pas que déclarer les variables en début de fonction soit un progrès en terme de maintenabilité et de clarté de code. C'est surtout plus clair pour ceux qui ont une grosse expérience dans des langages qui l'impose.
D'ailleurs, historiquement cette restriction n'a pas été imposée pour une meilleur lisibilité, mais pour simplifier l'écriture du compilateur.
Dans beaucoup de cas, je trouve que la déclaration de variables à l'endroit de leur emploi facilite la compréhension du code.
Si c'est en réponse à ma diatribe, je te rassures: je parlais plus du fait d'utiliser un mode verbeux dans l'écriture du code que de la déclaration anticipée des variables...
Mais, ceci dit, *certains* préfèrent avoir la liste de toutes les variables au début, et d'autres préfèrent avoir la déclaration au moment où il est possible d'en définir la valeur.
La déclaration au moment de l'initialisation avec une valeur directement correcte présente quelques avantages certains, dont, entre autre, une portée plus controlée, et il est de bon ton de s'y habituer...
Cependant, malgré les avantages de la déclaration juste avant l'utilisation, je ne jetterai jamais la pierre à quelqu'un qui, pour une raison quelconque, décidera d'utiliser une déclaration anticipée...
me voilà donc rassuré :)