IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

 C++ Discussion :

Plus d'appel au destructeur qu'au constructeur ?


Sujet :

C++

  1. #21
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Bousk Voir le message
    En même temps, ça fait 3 posts que je le dis qu'une copie c'est un gachis de mémoire. Et que const n'a rien à voir et ne sert à rien. Donc je vois pas comment tu peux comprendre/croire que je lie le const à un gachis de mémoire... sauf à extrapoler quand la copie constante nous force à refaire une copie non constante, ce qui est un double gachis mémoire, mais dont la source est toujours la copie inutile.
    A vrai dire, je réagissais surtout à
    Quand un étudiant me montre une copie constante, je le renvois illico. Soit il fait une copie et il assume et il sait le justifier. Soit il fait une const&.
    car je suis désolé, mais, conceptuellement parlant, il n'y a absolument rien qui justifie de l'interdire...

    En effet, reprenons tout depuis le début et revenons un tout petit peu aux "basiques" (je sais, tu les connais déjà depuis longtemps ):
    A quoi sert un paramètre pour une fonction
    Un paramètre de fonction correspond à une donnée pour laquelle la fonction appelée est incapable de définir une valeur (un état) par elle-même.

    Le paramètre en question a pour résultat de déclarer une variable du type et du nom indiqué accessible au sein de la fonction.
    A quoi sert la notion de référence
    La notion de référence nous permet essentiellement de faire en sorte que les modifications éventuelles apportées par la fonction appelée au paramètre transmis par référence soient répercutées sur la variable qui a servi d'argument dans la fonction appelante. Accessoirement, le passage par référence permet d'éviter le phénomène de copie lié au passage par valeur

    Note que j'aurais pu énoncer les choses sous un point de vue différent :
    La notion de référence nous permet de transmettre une variable comme argument lors de l'appel d'une fonction en éitant le phénomène de copie de cette variable au niveau de la fonction appelée. Elle présente néanmoins "l'effet secondaire" de faire en sorte que toute modification apportée au paramètre transmis par référence au niveau de la fonction appelée sera répercutée sur la variable qui a servi d'argument au niveau de la fonction appelante.

    A quoi sert la constante
    La constante permet d'indiquer explicitement au compilateur qu'il doit veiller à ne pas autoriser la modification de la variable (au sens le plus large possible) auquel elle se rapporte.

    Cela impose un "contrat" que le compilateur est parfaitement en mesure de faire respecter : la variable ne peut en aucun cas être modifiée.

    Maintenant que nous avons repris nos basiques, réfléchissons un peu au différentes combinaisons :
    Variable et constante :
    Il n'y a absolument rien qui t'interdise de déclarer une variable locale comme étant constante : cela ne fait rien d'autre que la transformer en "constante locale" : Je n'aurais, par exemple, aucun problème avec l'idée d'écrire un code proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    /* Fonction lisant 10 fichiers dont seul le suffixe est différent */
    void foo(){
        std::string const base{"chemin/vers/fichier"};
        std::string const ext{".ext"};
        for(int i=1;i<11;++i){
            std::string filename(base);
            filename.append(std::to_string(i)
                    .append(ext);
            std::ifstream ifs(filename);
            if(ifs){
            /* ... */
           }
        }
    }
    A vrai dire, j'y verrais même deux avantages :

    Primo : j'indique explicitement au lecteur du code que les chaines de caractères base et ext n'ont pas vocation à être modifiée
    Secundo : Je m'assure que le compilateur m'engueulera si, à un moment ou à un autre, je venais à essayer de modifier la valeur de ces chaines de caractères.

    référence et constante?
    Avant de nous intéresser à la raison qui nous poussera à transmettre un paramètre sous la forme d'une référence constante, intéressons nous aux raisons qui nous pousseront à transmetre un paramètre sous la forme d'une référence (non constante):

    On peut décider de le faire pour deux raisons :

    - Soit parce que l'on souhaite effectivement que les modifications appliquées au paramètre dans la fonction appelée soient répercutées à la fonction dans la fonction appelante. D'une certaine manière, le fait que l'on évite également la copie de l'argument n'est à considérer que comme un "bonus supplémentaire"
    - Soit parce que l'on souhaite effectivement éviter le phénomène de copie lié au passage par valeur. Le fait que les modifications appliquées au paramètre dans la fonction appelée soient répercutées sur l'argument utilisé dans la fonction appelante est alors considéré un "effet secondaire potentiellement non souhaitable".

    D'une certaine manière, le passage par référence constante n'aura réellement du sens que si cet effet secondaire n'est ni souhaitable ni souhaité.

    valeur constante?

    La constante en elle-même n'indique qu'une seule chose : la fonction appelée ne peut pas modifier la variable correspondante. Le fait que l'on passe le paramètre par valeur au lieu de le passer par référence semble indiquer qu'il y aura copie. Mais la question est "le passage par référence constante évitera-t-il effectivement qu'il n'y ait construction (par copie ou non) d'une variable locale à la fonction appelée "

    La réponse à cette question est, malheureusement, non...

    Reprenons la fonction que je présentais en exemple, et modifions la de manière à faire en sorte qu'elle accepte un paramètre indiquant le chemin à suivre pour accéder au fichier sous une forme proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    void foo(std::string const & path){
        std::string const base{"fichier"};
        std::string const ext{".ext"};
        for(int i=1;i<11;++i){
            std::string filename(base);
            filename.append(path)
                    .append(std::to_string(i)
                    .append(ext);
            std::ifstream ifs(filename);
            if(ifs){
            /* ... */
           }
        }
    }
    Le passage par référence constante est sensé éviter la création d'une copie, c'est à dire que nous l'éviterons si on appelle cette fonction sous une forme proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    int main(){
       std::string /* const */ path{"chemin/a/suivre"};
       foo(path);
    }
    Mais on ne peut ignorer le fait que de nombreux appels à cette fonction pourraient prendre la forme de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    int main(){
        foo("chemin/ecrit/en/dur");
    }
    Et que cela occasionnera de toutes façons la création d'une variable temporaire anonyme au niveau de la fonction appelante. A ce stade, l'intérêt du passage par référence qui est d'éviter la copie devient strictement minimal alors que celui de transmettre une valeur constante reste tout à fait capital : le compilateur nous engueulera si on essaye de modifier la valeur de ce paramètre dans la fonction appelée.

    Je ne vois donc absolument rien qui puisse justifier d'un point de vue conceptuel de refuser un passage par valeur constante sous la forme de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    void foo(std::string const path){
        std::string const base{"fichier"};
        std::string const ext{".ext"};
        for(int i=1;i<11;++i){
            std::string filename(base);
            filename.append(path)
                    .append(std::to_string(i)
                    .append(ext);
            std::ifstream ifs(filename);
            if(ifs){
            /* ... */
           }
        }
    }
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  2. #22
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 186
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 186
    Points : 17 126
    Points
    17 126
    Par défaut
    Je suis bien d'accord avec l'intérêt de const.
    Cela dit, une référence apporte un gain et aucune perte par rapport à une copie.

    Pour conséquence, le fait d'être constante n'intéresse pas l'utilisateur d'une fonction prenant son argument par copie.
    C'est d'ailleurs pour cela que const et volatile ne sont pas pris en compte dans la différenciation des fonctions.

    Du coup, j'aurai tendance à dire qu'il vaut mieux déclarer les fonctions sans const, et les définir avec, si on en ressent le besoin.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  3. #23
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par leternel Voir le message
    Je suis bien d'accord avec l'intérêt de const.
    Cela dit, une référence apporte un gain et aucune perte par rapport à une copie.

    Pour conséquence, le fait d'être constante n'intéresse pas l'utilisateur d'une fonction prenant son argument par copie.
    C'est d'ailleurs pour cela que const et volatile ne sont pas pris en compte dans la différenciation des fonctions.

    Du coup, j'aurai tendance à dire qu'il vaut mieux déclarer les fonctions sans const, et les définir avec, si on en ressent le besoin.
    Attention, comme tu l'indiques si bien, ils ne sont pas pris en compte lors de la différenciation des fonctions (du moins pour le passage par valeur).

    Je suis donc tout à fait d'accord avec ton analyse selon laquelle le fait qu'une fonction prenne son paramètre par valeur constante n'intéresse pas l'utilisateur de la fonction.

    Par contre, le fait qu'une variable (éventuellement obtenue au travers d'un paramètre qui lui a été transmis) intéresse au plus haut point le développeur de la fonction et participe au respect de certains contrats, ce qui justifie à lui seul le fait de déclarer la variable (ou le paramètre) en question comme étant constant(e).

    En outre, je ne partage pas ton avis en ce qui concerne l'idée de déclarer une fonction prenant un paramètre par valeur non constant et de la définir comme prenant ce paramètre sous une forme constante car, bien que le compilateur n'y fasse pas attention du tout, le lecteur du code prendra forcément la présence (ou l'absence) du mot clé const en compte.

    Le fait de trouver la définition d'une fonction qui ne corresponde pas (à cause de la présence du mot clé const ou volatile) à sa déclaration contraindrait le lecteur du code à la gymnastique intellectuelle qui consiste à se rappeler que "mais oui, en effet, const et volatile n'interviennent pas dans la différentiation lors du passage par valeur".

    En "lecture rapide", le lecteur risque fort de ne pas faire cette gymnastique intellectuelle et sera donc sans doute particulièrement désorienté par cette différence. Sans oublier les problèmes que cela pourrait occasionner au niveau de la recherche ou au niveau de fonctionnalités de certains IDE permettant de "switcher" entre la déclaration et l'implémentation de fonctions.

    N'ayant, jusqu'à présent, pas eu le moindre argument judicieux motivant le fait de ne pas passer une valeur constante comme paramètre, et n'ayant pas d'avantage été séduit par l'idée de déclarer les fonctions sous une forme et de les définir sous une autre, j'en reste donc à mon idée première : peu importe que ce soit par valeur ou par référence, si la fonction appelée ne doit pas avoir la possibilité de modifier un paramètre qu'elle a obtenu, il faut le déclarer explicitement comme étant constant
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  4. #24
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 958
    Points
    32 958
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Par contre, le fait qu'une variable (éventuellement obtenue au travers d'un paramètre qui lui a été transmis) intéresse au plus haut point le développeur de la fonction et participe au respect de certains contrats, ce qui justifie à lui seul le fait de déclarer la variable (ou le paramètre) en question comme étant constant(e).
    Trouve-moi 1 seul exemple d'une quelconque utilité (utilité réelle, pas de "ça m'évite les fautes de frappe en modifiant un paramètre et non une variable interne à ma fonction" - va renommer correctement tes variables pour faire des étourderies pareilles) à un paramètre passé par copie constante. Un seul contrat qui nécessite qu'un paramètre soit une copie constante.
    Si la réponse est, telle que ma petite expérience l'indique ainsi que le bon sens, un bon gros AUCUN, alors je vous renvois vers la lecture de mon 1° post et oui je n'ai aucun regret à indiquer à mes étudiants qu'une copie const en paramètre est une bétise et n'a absolument pas lieu d'être, et qu'en tant que telle, donc on ne l'écrit pas.

    Pour me répéter : que le contrat indique une copie constante est absurde : c'est déjà une copie, donc l'original n'est pas modifié, donc il peut bien en faire une copie, ça m'en touche une sans bouger l'autre et je m'en tamponne l'oreille avec une babouche à clochette.
    Et c'est bien tout ce qui m'intéresse dans le contrat avec cette fonction : l'objet que je lui passe en paramètre n'est pas altéré!

    Je ne vois donc absolument rien qui puisse justifier d'un point de vue conceptuel de refuser un passage par valeur constante sous la forme de
    oui tout comme on peut mettre des ; à l'infini en fin d'instruction, après les accolades d'un for, ... des exemples stupides existent à la pelle, ça n'en est pas moins des bétises qu'il vaut mieux faire comprendre à un étudiant/débutant que de le laisser errer dans son capharnaüm.

    "mais oui, en effet, const et volatile n'interviennent pas dans la différentiation lors du passage par valeur".

    En "lecture rapide", le lecteur risque fort de ne pas faire cette gymnastique intellectuelle et sera donc sans doute particulièrement désorienté par cette différence.
    Un lecteur, rapide ou non, n'en aura strictement rien à faire de la constante, il ne s'intéressera qu'à l'absence de référence ou pointeur pour savoir que son objet n'est pas altéré par l'appel à cette fonction.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  5. #25
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Points : 16 213
    Points
    16 213
    Par défaut
    Je suis en léger désaccord avec deux points dans la discussion précédente :
    - Le passage par référence est forcément plus rapide : Ce passage permet de l'aliasing entre les différents paramètres, ce qui peut empêcher le compilateur de générer le code le plus optimal possible. Certaines personnes ont mesuré un réel impact sur du code de production où on allait plus vite en passant des std::string par copie que par référence constante. Il y a aussi quelques cas rares (on initialise une donnée à partir de la valeur passée en argument, cette valeur pouvant être un temporaire) où le passage par copie peut économiser la création d'un objet supplémentaires dans certains cas d'utilisation. Alors certes, le conseil classique reste d'actualité. Mais ce n'est pas forcément une vérité absolue.

    - Le const ne sert à rien pour un passage par valeur : Certes, le const dans un tel cas ne modifie en rien l'interface de la fonction. Il n'en fait d'ailleurs pas partie. Et globalement, il aura peu d'effet sur le code généré (peu, mais pas aucun : je peux bien entendu manipuler une classe qui propose deux surcharges différentes selon que l'objet est const ou pas, aux performances différentes, par exemple). Mais si j'ai envie dans l'implémentation de ma fonction de m'assurer que je ne modifie pas par erreur la valeur de ce paramètre passé par copie, pourquoi vouloir m'empêcher de mettre en place cette sécurité supplémentaire ? Est-ce que le fait de déclarer const des variables locales est légitime (je pense que oui, légitime même si pas indispensable) ? Si oui, déclarer const des paramètres passés par valeur l'est aussi, car c'est exactement la même chose.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  6. #26
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Bousk Voir le message
    Trouve-moi 1 seul exemple d'une quelconque utilité (utilité réelle, pas de "ça m'évite les fautes de frappe en modifiant un paramètre et non une variable interne à ma fonction" - va renommer correctement tes variables pour faire des étourderies pareilles) à un paramètre passé par copie constante. Un seul contrat qui nécessite qu'un paramètre soit une copie constante.
    J'espère, en effet, ne jamais perdre la tete au point d'oublier, au moment d'implémenter une fonction, que j'ai décidé qu'une variable (locale ou reçue au travers d'un paramètre) n'avait pas lieu à être modifiée

    Cependant :
    Si la réponse est, telle que ma petite expérience l'indique ainsi que le bon sens, un bon gros AUCUN, alors je vous renvois vers la lecture de mon 1° post et oui je n'ai aucun regret à indiquer à mes étudiants qu'une copie const en paramètre est une bétise et n'a absolument pas lieu d'être, et qu'en tant que telle, donc on ne l'écrit pas.
    Je reste en total désaccord avec toi sur ce coup :

    Le mot clé const indique très clairement la volonté du développeur qui implémente une fonction, au même titre que le choix judicieux des identifants (noms de type, de variable, de paramètres, ...) permet d'indiquer très clairement le but ou la raison d'être de chaque élément.

    Je ne vais, très certainement pas développer une fonction en me disant "tiens, telle variable ne sera jamais modifiée" et essayer de la modifier dix lignes plus bas (et je te l'ai dit, j'espère ne jamais arriver à ce stade) : je ne suis pas encore assez sénile pour le faire.

    Par contre, j'estime que mon code doit être la meilleure source possible de documentation pour tous ceux qui devront le lire / le modifier par la suite. Cela sous entend également le type qui devra s'intéresser à ce que j'ai écrit dans dix ans, parce qu'il vient de reprendre la (maintenance? évolution ?) d'un projet auquel je n'aurai plus pensé depuis longtemps.

    A ce titre le mot clé const présente un avantage énorme : lorsque tu le rencontre, tu sais exactement quelles étaient les intentions du développeur : la valeur ne sera pas modifiée. Cela va de pair avec un corrollaire des plus agréables d'ailleurs : Si la valeur est correcte lorsqu'elle est définie, tu n'as plus besoin de t'en inquiéter par la suite, elle restera correcte quoi qu'il arrive. (y compris, et essentiellement lorsque le débuggeur rentre en jeu )
    Pour me répéter : que le contrat indique une copie constante est absurde : c'est déjà une copie, donc l'original n'est pas modifié, donc il peut bien en faire une copie, ça m'en touche une sans bouger l'autre et je m'en tamponne l'oreille avec une babouche à clochette.
    Et c'est bien tout ce qui m'intéresse dans le contrat avec cette fonction : l'objet que je lui passe en paramètre n'est pas altéré!
    Je te comprends, mais, à mon sens, cela va beaucoup plus loin que cela...

    Tu connais mon point de vue : je préférerai toujours un code qui fonctionne correctement à un code rapide s'il doit en arriver à faire n'importe quoi.

    A ce titre, un code const-correct apporte énormément de garanties que l'on ne pourrait avoir avec un code non const-correct qu'en le décortiquant avec le plus grand soin.

    Dé lors, c'est peut être absurde, mais c'est viscérale chez moi : si je devais "pénaliser" le fait de transmettre par valeur constante et / ou par référence non constante des paramètres qui devraient (en toute logique) être transmis par référence constante, je pénaliserait le passage par référence non constante bien plus fermement (et fortement) que le passage par valeur constante.

    Et cela, pour une raison bien simple :

    Il suffira de transformer la valeur constante en référence constante dans le prototype pour résoudre les problèmes de performances, sans avoir à modifier la moindre ligne d'implémentation, vu que tout a déjà été mis en oeuvre pour respecter la constance des valeurs.

    A contrario, tu ne peux pas forcément avoir ce genre de garantie avec un passage par référence non constante : cela demande beaucoup plus de travail pour s'en assurer et, surtout, cela pourrait mener à des dérives au niveau du code pour éviter que le paramètre ne soit modifié qui pourraient prendre une forme (caricaturale, je te l'accorde ) proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    void foo(Type & ref){
        Type cache(ref);
        /* modification de ref à sa guise ici 
         * ...
         */
        ref = cache;
    }
    Encore une fois, je comprends ton point de vue et je le respecte au plus haut point. Simplement, je ne suis pas tout à fait d'accord avec toi (bien que globalement d'accord sur le principe )

    EDIT : En fait, ce que je voulais surtout dire lorsque j'ai décidé d'intervenir sur cette discussion pourrait se résumer à ceci : Je suis tout à fait d'accord que le passage d'un paramètre par valeur constante n'est pas bon, mais c'est "moins pire" et "plus facile à accepter" grâce à la valeur "informative" (au sens le plus large possible du terme) du mot clé const que les autres erreurs que l'on pourrait commettre au niveau du passage de paramètres
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #27
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    5 186
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 5 186
    Points : 17 126
    Points
    17 126
    Par défaut
    Citation Envoyé par koala01 Voir le message
    A ce titre, un code const-correct apporte énormément de garanties que l'on ne pourrait avoir avec un code non const-correct qu'en le décortiquant avec le plus grand soin.

    Dès lors, c'est peut être absurde, mais c'est viscérale chez moi : si je devais "pénaliser" le fait de transmettre par valeur constante et / ou par référence non constante des paramètres qui devraient (en toute logique) être transmis par référence constante, je pénaliserait le passage par référence non constante bien plus fermement (et fortement) que le passage par valeur constante.

    Et cela, pour une raison bien simple :

    Il suffira de transformer la valeur constante en référence constante dans le prototype pour résoudre les problèmes de performances, sans avoir à modifier la moindre ligne d'implémentation, vu que tout a déjà été mis en oeuvre pour respecter la constance des valeurs.

    A contrario, tu ne peux pas forcément avoir ce genre de garantie avec un passage par référence non constante : cela demande beaucoup plus de travail pour s'en assurer et, surtout, cela pourrait mener à des dérives au niveau du code pour éviter que le paramètre ne soit modifié qui pourraient prendre une forme (caricaturale, je te l'accorde ) proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    void foo(Type & ref){
        Type cache(ref);
        /* modification de ref à sa guise ici 
         * ...
         */
        ref = cache;
    }
    Encore une fois, je comprends ton point de vue et je le respecte au plus haut point. Simplement, je ne suis pas tout à fait d'accord avec toi (bien que globalement d'accord sur le principe )

    EDIT : En fait, ce que je voulais surtout dire lorsque j'ai décidé d'intervenir sur cette discussion pourrait se résumer à ceci : Je suis tout à fait d'accord que le passage d'un paramètre par valeur constante n'est pas bon, mais c'est "moins pire" et "plus facile à accepter" grâce à la valeur "informative" (au sens le plus large possible du terme) du mot clé const que les autres erreurs que l'on pourrait commettre au niveau du passage de paramètres
    C'est de ce point de vue que je regrette que ce soit la référence constante qui demande un spécifieur plutot que la référence modifiante.

    J'aurai préféré qu'une référence constante soit notée avec le &, et une référence modifiante avec volatile&
    Au moins, les références modifiantes seraient explicites, et demanderait un gros travail.
    Cela dit, question sémantique du langage, ce choix aurait été moins bon.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Discussions similaires

  1. appeler le destructeur dans une fonction
    Par asoka13 dans le forum C++
    Réponses: 3
    Dernier message: 12/05/2008, 01h24
  2. [POO] Appel des destructeurs
    Par Merfolk dans le forum Langage
    Réponses: 2
    Dernier message: 28/03/2008, 18h59
  3. Réponses: 3
    Dernier message: 31/07/2007, 22h18
  4. [Loufoque] Appel de destructeur
    Par Chii-san dans le forum C++
    Réponses: 12
    Dernier message: 18/05/2006, 11h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo