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 :

Const sur argument passé par copie


Sujet :

C++

  1. #1
    Membre averti Avatar de Seabirds
    Homme Profil pro
    Post-doctoral fellow
    Inscrit en
    Avril 2015
    Messages
    294
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Post-doctoral fellow
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : Avril 2015
    Messages : 294
    Points : 341
    Points
    341
    Par défaut Const sur argument passé par copie
    Salut,

    En lisant un code je suis tombé sur une signature ressemblant a ça:

    int foo(const size_t a, const size_t b)
    Mon premier réflexe a été de me dire que le const devant des arguments passés par copies c’était superflu, mais en allant fouiller j'ai vu qu'il y avait tout un débat la dessus.

    Vous en pensez quoi ?
    Le débutant, lui, ignore qu'il ignore à ce point, il est fier de ses premiers succès, bien plus qu'il n'est conscient de l'étendue de ce qu'il ne sait pas, dès qu'il progresse en revanche, dès que s'accroît ce qu'il sait, il commence à saisir tout ce qui manque encore à son savoir. Qui sait peu ignore aussi très peu. [Roger Pol-Droit]
    Github
    Mon tout premier projet: une bibliothèque de simulation de génétique des populations

  2. #2
    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
    Superflu et inutile dans le prototype.
    Dans l'implementation ca peut avoir un interet.
    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.

  3. #3
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2011
    Messages
    739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : Juin 2011
    Messages : 739
    Points : 3 627
    Points
    3 627
    Par défaut
    Dans l'implémentation, cela garanti que la valeur sera toujours celle d'origine quelle que soit la ligne regardée. Il n'y a plus besoin à se demander si la variable est modifiée puisqu'elle ne le sera jamais. Pour les fonctions de quelques lignes c'est évident, mais beaucoup moins lorsque quelle grossie. Au final, c'est comme toutes les variables constantes.

    Dans un prototype, c'est plus une surcharge visuelle qu'autre chose.

  4. #4
    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
    Salut,

    Je au contraire que c'est parfaitement normal de déclarer un paramètre comme constant et ce quel que soit la manière dont il est transmis (par copie, par référence ou par pointeur).

    En effet la constance doit être envisagée de manière totalement indépendante de la manière à laquelle nous pourrons accéder à la donnée, car elle représente un invariant stricte : la donnée à laquelle nous voulons accéder ne peut pas être modifiée. Et le mieux de l'histoire, c'est que le compilateur pourra gueuler si tu essaye d'ignorer cet invariant.

    Quand on réfléchit à la possibilité de déclarer une donnée comme étant constante, on se fout pas mal de savoir s'il y a eu copie ou non, si on a pris l'adresse de la donnée ou non. On veut juste garantir que la donnée ne sera pas modifiée.

    Avec un code proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    void foo(int const a, int const b);
    on exprimer clairement le fait que foo ne pourra modifier ni a ni b, et le compilateur sera là pour y veiller

    Mieux encore : cela permet de rappeler à celui qui lira le code de foo qu'il ne peut pas essayer de modifier la valeur de a ou de b. S'il doit modifier la fonction foo, il devra prendre cette restriction en compte (et, encore une fois, le compilateur sera là pour veiller à ce qu'il le fasse )

    Pour les types primitifs, ce n'est pas la transmission sous forme de constante qui n'a guère d'intérêt, mais bien la transmission par référence constante plutot que par copie.

    En effet, si l'on observe un peu l'assembleur généré lorsque l'on manipule des références, nous nous rendons compte que c'est l'adresse de la variable qui est utilisée. Et oui, au niveau du processeur, une référence est représentée exactement de la même manière qu'un pointeur!!!

    Ot; une adresse mémoire, ce n'est jamais qu'une valeur numérique entière (généralement non signée) représentée par un nombre de bits au minimum suffisant que pour pouvoir représenter l'ensemble des adresses mémoires auxquelles l'ordinateur a accès.

    Sur les architectures "classiques" de PC, on peut donc estimer que c'est une valeur numérique représentée sur un nombre de bits variant de 32 à 64 (en gros, la taille d'un /* unsigned*/ int ou d'un /* unsigned*/ long long, selon les architectures )

    On se rend donc compte que, s'il faut utiliser 32 ou 64 bits (pour pouvoir représenter l'adresse mémoire d'une donnée qui aurait pu tenir sur "moins que cela" (comme un char ou un short) ou sur "à peu près autant que cela" (comme un int,un long, un long long, un float, un double ou un long double), cela occasionnerait un "fameux gâchis d'espace", car nous pourrions (dans le meilleur des cas) faire passer entre deux et huit valeurs en même temps, et cela sans que la copie ne prenne plus de temps que le fait de transmettre l'adresse mémoire de la donnée.

    C'est pour cela que l'on propose la règle de transmettre par copie tout ce qui "prend moins d'espace mémoire qu'un pointeur" (autrement dit les types primitifs) et par référence (éventuellement constante, si on ne veut pas pouvoir modifier l'objet original) tout ce qui est "plus gros qu'un pointeur". A moins, bien sur, que tu ne veuilles pouvoir modifier la donnée originale (de type primitif) que tu transmet à ta fonction.

    Mais, s'il faut mettre deux choses en oppositions, ce n'est pas le passage par copie et la constante: il faut mettre le passage copie en opposition avec le passage par référence. La constance de la donnée, c'est quelque chose qui n'a strictement rien à voir avec les notions de copie Vs référence Vs pointeur.
    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

  5. #5
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    393
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 393
    Points : 684
    Points
    684
    Par défaut
    Citation Envoyé par koala01 Voir le message
    On veut juste garantir que la donnée ne sera pas modifiée.
    De quelle donnée on parle ?

    L’intérêt de l'interface publique, c'est d'informer l'utilisateur sur comment utiliser la fonction, sans se préoccuper de l’implémentation. Ce qui l’intéresse, c'est de savoir que s'il écrit :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    int i { 123 };
    int j { 456 };
    foo(i, j);
    ses variables i et j ne seront pas modifiées. Que les paramètres soient const ou non lors d'un passage par valeur ne change rien a cette garantie. Dans les 2 cas, l'appelant sait que ses variables ne sont pas modifiées. De son point de vue, const ne sert a rien.

    Du point de vue ce celui qui va implémenter la fonction, quel est l’intérêt d'avoir une contrainte sur lui, mais qui n'a aucun impact pour les utilisateurs de la fonction ? Pourquoi devoir lui imposer une copie du paramètre const, s'il a besoin de travailler sur cette valeur, alors que le const ne sert a rien ?

    Donc a mon sens : c'est inutile. Ca n'apporte rien a l'utilisateur de la fonction, et c'est une contrainte inutile pour celui qui ecrit la fonction.

  6. #6
    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 mintho carmo Voir le message
    De quelle donnée on parle ?
    De n'importe quelle donnée!!!

    Surtout si la donnée est transmise (d'une manière ou d'une autre) à une fonction !!!

    Je vais aborder une notion qui est d'avantage utilisée en programmation fonctionnelle, mais, on se rapproche de l'occasion d'apporter la preuve qu'une fonction est "pure" (quelle ne modifie aucun des arguments qu'elle reçoit en paramètre)
    Citation Envoyé par mintho carmo Voir le message
    L’intérêt de l'interface publique, c'est d'informer l'utilisateur sur comment utiliser la fonction, sans se préoccuper de l’implémentation. Ce qui l’intéresse, c'est de savoir que s'il écrit :
    Et, parce que le code s'adresse aussi bien au développeur qu'au compilateur (faut pas l'oublier, lui ) de permettre au compilateur de s'assurer que les invariants que l'on place sur une donnée (quelle qu'elle soit, quelle que soit la manière dont la fonction l'a reçue) seront respectés.

    Cela s'intègre parfaitement dans une politique qui tend à faire passer le compilateur du statut de "simple outil" (destiné à générer le code binaire exécutable) au statut d'allier (capable de garantir la qualité du code écrit) et qui est exactement la même que celle qui nous incite à déclarer la redéfinition des fonctions virtuelles comme étant override ou même final override
    Citation Envoyé par mintho carmo Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    int i { 123 };
    int j { 456 };
    foo(i, j);
    ses variables i et j ne seront pas modifiées. Que les paramètres soient const ou non lors d'un passage par valeur ne change rien a cette garantie. Dans les 2 cas, l'appelant sait que ses variables ne sont pas modifiées. De son point de vue, const ne sert a rien.
    Je t'accorde que cela ne change rien dans la fonction appelante.

    Mais ajouter la constance à un paramètre a pour but d'apporter la garantie dans la fonction appelée (donc dans foo).

    Après, que cette garantie puisse servir à "rassurer" le développeur de la fonction appelante, c'est un autre problème

    Ce que la constance a pour but de garantir, c'est que les valeurs qui sont transmises à foo ne changeront pas, peu importe que ces valeurs aient été transmises par bar, par doSomething ou par main.

    Parce que, lorsque l'on regarde le corps de foo, on sait -- au mieux -- que l'on a reçu deux paramètres de type int, mais on ne peut en aucun cas spéculer sur l'origine de ces deux paramètres.

    En indiquant que foo s'attend à recevoir deux paramètres constant, cela revient -- dans le corps de foo -- à peu près au même que si on avait écrit un code proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    void foo(){
        int const i{35};
        int const j{48};
        /* on peut utiliser i et j, mais on pourra pas les modifier ici */
    }
    A la seule différence que i et j viennent "d'ailleurs" (quand elles sont transmise en argument) parce que la fonction n'est pas en mesure de définir la valeur de ces données.

    Citation Envoyé par mintho carmo Voir le message
    Du point de vue ce celui qui va implémenter la fonction, quel est l’intérêt d'avoir une contrainte sur lui, mais qui n'a aucun impact pour les utilisateurs de la fonction ?
    Que penses tu de la garantie d'avoir affaire à une donnée immuable, qui pourra être controlée par le compilateur :question;

    Pourquoi vas tu t'amuser à écrire un code proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    void bar(){
        const int size{53};
        /* ... */
    }


    Pourquoi la valeur de size devrait elle obligatoirement être connue de la fonction bar

    Pourquoi ne pourrait-elle pas être "définie par ailleurs", et donc, obtenue sous la forme d'un paramètre (ou renvoyée par une fonction à laquelle nous ferions appel)

    En un mot, pourquoi une valeur constante ne pourrait-elle pas être reçue comme paramètre

    Après tout, on le fait régulièrement lorsque l'on transmet des classes et des structure imposantes par référence (dans le but d'en éviter la copie), non

    Cela a -- bien sur -- un attrait du fait même de la mécanique des référence. Mais cela impose aussi des restrictions quant à l'usage que l'on pourra faire de ces données.

    Dés lors, pourquoi serait il "sensé" d'imposer la constance à ce qui est transmis par référence et ... insensé de le faire à ce qui est transmis par copie parce qu'une valeur copiée devra forcément être modifiée Mais il n'y a aucune règle qui l'impose, que je sache !!!

    Bien au contraire! la notion de fonction pure dont j'ai parlé plus tôt nous inciterait justement à faire en sorte de nous assurer que les paramètres reçus sous n'importe quelle forme ne soient jamais modifiés!!!

    Citation Envoyé par mintho carmo Voir le message
    Pourquoi devoir lui imposer une copie du paramètre const, s'il a besoin de travailler sur cette valeur, alors que le const ne sert a rien ?
    Mais, qui te dit qu'il ne doit pas -- justement -- travailler sur une valeur immuable

    Tu semble partir du principe que l'on va forcément vouloir modifier une donnée reçue par copie. Mais il n'y a rien qui t'oblige à le faire!

    Et si tu estimes que la donnée en question doit être immuable, la meilleure chose à faire pour garantir que l'immuabilité sera respectée est encore... de déclarer cette donnée comme constante

    Citation Envoyé par mintho carmo Voir le message
    Donc a mon sens : c'est inutile. Ca n'apporte rien a l'utilisateur de la fonction, et c'est une contrainte inutile pour celui qui ecrit la fonction.
    Nuance : c'est une contrainte potentiellement inutile pour celui qui écrit la fonction. Parce que tu ne vois, pour l'instant, aucune situation dans laquelle elle pourrait se justifier.

    Mais ce n'est pas parce que tu ne vois -- "à l'instant même" -- aucun cas dans lequel cela pourrait se justifier que tu ne seras pas confronté -- dans deux heures ou dans deux ans -- à un cas dans lequel ce sera pleinement justifié.

    Je ne dis nullement qu'il faut en faire une règle générale, mais je dis que tu rencontreras forcément des situations dans lesquelles la fonction que tu dois développer va recevoir des données par copie qu'elle ne pourra pas modifier.

    Et je dis donc seulement qu'il ne faut pas écarter définitivement la possibilité de transmettre un paramètre par copie constante uniquement sous prétexte que l'on ne voit pas pourquoi on le ferait à l'instant même.

    Encore une fois, s'il faut mettre le passage par copie en opposition à "autre chose", c'est au passage par référence et / ou au passage par pointeur. Le problème de la constance des paramètres transmis n'a rien à voir avec la forme sous laquelle on transmet ces paramètres.

    Alors, bien sur, il se fait que, pas de bol, si un paramètre est reçu sous la forme d'une référence ou d'un pointeur, les modifications apportées au niveau de la fonction appelée seront répercutées sur les données qui servent d'argument au niveau de la fonction appelante. Et il se fait que cela rassurera sans doute le développeur de la fonction appelante de savoir que les données transmises comme argument ne seront pas modifiées.

    Mais le problème n'est pas là : le problème est surtout de déterminer précisément ce que la fonction appelée a le droit de faire (ou plutôt, ce qu'elle n'a pas le droit de faire) avec les paramètres qui lui ont été transmis (sous quelle que forme que ce soit).
    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. #7
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Dés lors, pourquoi serait il "sensé" d'imposer la constance à ce qui est transmis par référence et ... insensé de le faire à ce qui est transmis par copie parce qu'une valeur copiée devra forcément être modifiée Mais il n'y a aucune règle qui l'impose, que je sache !!!

    Bien au contraire! la notion de fonction pure dont j'ai parlé plus tôt nous inciterait justement à faire en sorte de nous assurer que les paramètres reçus sous n'importe quelle forme ne soient jamais modifiés!!!
    Dans l'implémentation d'une fonction foo, déclarer comme constant un paramètre passé par copie peut être sensé, pour la même raison que déclarer comme constante une variable locale peut être sensé, mais ça n'a pas de rapport avec le fait que foo soit pure ou impure.
    Si foo est une fonction pure, alors elle doit être déterministe, ne pas avoir d'effet de bord et ne pas modifier les paramètres passés par référence, mais elle peut modifier localement les paramètres passés par copie.

  8. #8
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    393
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 393
    Points : 684
    Points
    684
    Par défaut
    Citation Envoyé par koala01 Voir le message
    De n'importe quelle donnée!!!
    C'etait une question rethorique.

    Un si long message pour expliquer (ou plutot reexpliquer) une seule idee : a quoi sert const.

    Mais cela n'entre pas en contradiction avec ce qui a ete dit. Pour l'utilisateur de la fonction, le const dans l'interface ne lui apporte aucune garantie. Pour celui qui implemente, c'est un detail d'implementation. S'il veut mettre const, qu'il le fasse. S'il veut modifier la valeur, qu'il ne le fasse pas.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    // dans le .h
    void foo(int, int);
     
    // dans le .cpp
    void foo(const int, const int) ...
    ou
    void foo(int, int) ...
    Ce sont les problematiques classiques de const, ce n'est pas specifique aux parametre de fonction.

  9. #9
    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 Pyramidev Voir le message
    <snip>mais elle peut modifier localement les paramètres passés par copie.
    Comme tu dis si bien: elle peut. Mais pouvoir n'est pas devoir que je sache!

    Et si le développeur de foo a une bonne raison d'imposer l'immuabilité des paramètres qu'elles reçoit -- fussent-ils transmis par copie -- il n'y a aucune raison à l'empêcher de les déclarer comme étant constant!

    Je t'accorde sans aucun problème que l'on a beaucoup plus de raison d'imposer la constance lors du passage par référence, ne serait-ce que pour éviter les effets de bords qui seraient occasionnés par une modification inopportune des données ainsi transmises, mais le fait reste que cela impose exactement les mêmes restrictions quant à l'emploi que l'on peut faire des données dans l'implémentation de la fonction appelée.

    Dés lors, sans même penser au éventuels effets de bords (car cela n'a aucune incidence dans le corps même de la fonction appelée), j'aimerais qu'on m'explique "par quelle magie" on en viendrait à trouver "tout à fait normal" d'imposer des restrictions à l'usage des paramètres obtenus par référence, et "tout à fait aberrant" d'imposer les mêmes restrictions aux paramètres obtenus par copie.

    Encore une fois, je n'ai jamais prétendu (et je ne prétendrai jamais) que le passage d'un paramètre constant devrait être la règle lors du passage par copie!

    Je soutiens simplement que si le développeur d'une fonction a de bonnes raisons de vouloir empêcher sa fonction de modifier un paramètre, il est tout à fait normal qu'il en vienne à le déclarer comme étant constant, quelle que soit la manière dont il est transmis à la fonction.

    Et, jusqu'à présent, aucun argument n'a pu me convaincre du contraire
    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

  10. #10
    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
    "tout à fait aberrant" d'imposer les mêmes restrictions aux paramètres obtenus par copie. [...] Je soutiens simplement que si le développeur d'une fonction a de bonnes raisons de vouloir empêcher sa fonction de modifier un paramètre, il est tout à fait normal qu'il en vienne à le déclarer comme étant constant, quelle que soit la manière dont il est transmis à la fonction.
    Mais la copie implique que le paramètre passé par l'utilisateur ne sera pas modifié. Et en tant qu'utilisateur c'est tout ce qui m'importe.
    Donc on tourne en rond : Inutile dans le prototype; redondant avec le fait d'être passé par copie.
    Si dans l'implémentation tu veux en plus ajouter un const pour ne pas la modifier tu peux le faire, et indépendamment du prototype qui plus est. Que demander de plus ?
    Mais en tant qu'utilisateur, const ou pas dans l'implémentation, const ou pas sur un paramètre passé par copie dans le prototype, ça m'en touche une sans bouger l'autre.
    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.

  11. #11
    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
    Mais la copie implique que le paramètre passé par l'utilisateur ne sera pas modifié. Et en tant qu'utilisateur c'est tout ce qui m'importe.
    Donc on tourne en rond : Inutile dans le prototype; redondant avec le fait d'être passé par copie.
    Ca implique que -- si modifications il y a au niveau de la fonction appelée -- les modifications ne seront pas répercutées au niveau de la fonction appelante!!! Nuance

    Quand on déclare une référence constante, on interdit à la fonction appelée de modifier le paramètre, entre autres, parce que, si modification il y a au niveau de la fonction appelée, elles seront répercutées au niveau de la fonction appelante, et que c'est une situation que l'on préfère éviter.

    Mais, si on laisse de coté la fonction appelante pour ne s'intéresser qu'à la fonction appelée, on se rend compte que variables et paramètres, correspondent à la même notion, avec juste un petit point de différence :c'est la représentation correcte d'une donnée particulière avec, comme seule différence entre les deux, l'endroit du code où la valeur "d'origine" de cette donnée a été définie: ce sera "en local" pour la variable et "ailleurs" (dans la fonction appelante ou l'une des fonctions appelées au par avant) pour le paramètre.

    Sauf, que, dans le corps de la fonction appelée, l'endroit du code ou la valeur d'origine de la donnée a été définie, on s'en fout pas mal! : on dispose d'une donnée qui a une valeur particulière à un instant T.

    Parfois, on décide que la valeur de cette donnée ne pourra pas être modifiée.

    La variable locale de la fonction appelée sera alors appelée constante, et nous ajouterons le mot clé const pour nous assurer que le compilateur nous interdira la modification.

    Lorsqu'il s'agit d'un paramètre, cette décision peut n'être prise que pour garantir à la fonction appelante que la donnée qui sert d'argument ne sera pas modifiée (e.a. si elle a été transmise par référence).

    Mais, tout comme le développeur de la fonction appelée peut déclarer une locale constante parce qu'il estime que la donnée n'a aucune raison valable de pouvoir être modifiée, il peut tout aussi bien décider que la donnée représentée par un paramètre obtenu par copie n'a ... aucun raison valable de pouvoir être modifiée.
    Si dans l'implémentation tu veux en plus ajouter un const pour ne pas la modifier tu peux le faire, et indépendamment du prototype qui plus est. Que demander de plus ?
    Et pourquoi attendre d'être dans le corps de la fonction pour rajouter cette constante

    D'abord, cela cache le fait que le paramètre ne sera pas modifié à celui qui lit le prototype; même si -- je suis tout à fait d'accord avec vous -- l'utilisateur de la fonction s'en fout, vu que c'est transmis par copie et qu'il sait donc que sa précieuse donnée ne sera pas modifiée

    Mais, surtout, cela t'oblige à créer une autre donnée locale que tu déclareras comme constante, alors que si tu l'avais directement mis dans le prototype, tu aurais obtenu direcement le même effet.

    Et, enfin, le prototype d'une fonction est sans doute la partie la plus stable d'une fonction: On peut sans doute en changer trente-six fois l'implémentation, mais le type de donnée renvoyée, le nom qui définit l'usage auquel la fonction est destinée et la liste des paramètres extérieurs dont elle a besoin pour travailler seront très rarement modifiés.

    Dés lors, même si quelqu'un décide de réécrire le code de la fonction (que ce soit à cause d'un bug ou pour mettre en place un algorithme plus efficace), le fait que le développeur d'origine ait dit "ce paramètre ne peut pas être modifié" (quelle que soit la forme sous laquelle il a été transmis ) représentera forcément une règle qui devra être respectée, quelque soit les modifications que nous pourrons apporter à l'implémentation.

    A l'inverse, si tu pars du principe que "bah, tout ce qui compte, c'est que l'utilisateur de la fonction sache que sa précieuse donnée ne sera pas modifiée, vu qu'elle est transmise par copie", tu cours forcément le risque que le type plein de bonne volonté qui modifie le corps de la fonction ne tienne pas compte du fait que cette valeur n'avait aucune raison d'être modifiée (au niveau de la fonction appelée, toujours).
    Mais en tant qu'utilisateur, const ou pas dans l'implémentation, const ou pas sur un paramètre passé par copie dans le prototype, ça m'en touche une sans bouger l'autre.
    Nous sommes bien d'accord. Mais ce n'est pas une information à l'usage exclusif de l'utilisateur! C'est une information à l'usage
    • du compilateur, qui pourra s'assurer que la restriction est respectée
    • de n'importe qui voulant vérifier, corriger ou modifier l'implémentation de la fonction
    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

  12. #12
    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
    A la limite, j'aimerais qu'on m'explique la raison de ce vote négatif...

    Car, si je suis tout à fait d'accord avec le fait que le prototype d'une fonction représente l'interface et que la règle est bel et bien de faire que
    une interface doit être facile à utiliser correctement et difficile à utiliser de manière incorrecte
    si je suis tout à fait d'accord avec le fait de déclarer un paramètre (transmis par copie) constant n'apporte rien à l'utilisateur de mon interface, il n'empêche que je suis le développeur de la fonctionnalité pour laquelle je crée l'interface aussi longtemps que je travaille sur l'implémentation de la fonction.

    Et, en tant que développeur de la fonctionnalité, ma priorité est de m'assurer que cette fonctionnalité produira exactement l'effet souhaité.

    Or, dans le cadre de cette priorité, il m'incombe régulièrement de m'assurer qu'une donnée (quelle qu'en soit l'origine, quelle que soit la manière dont elle a été transmise, s'il s'agit d'un paramètre) ne sera pas modifiée par l'implémentation de ma fonctionnalité.

    Pour obtenir une telle garantie, je dispose d'un allié de choix : le compilateur. Car, si je déclare une donnée comme étant constante, il m'interdira d'essayer de la modifier "par erreur". Que la donnée en question soit une valeur ou une référence, que ce soit une donnée locale ou une donnée "obtenue depuis l'extérieure"(autrement dit: un paramètre) ne changera rien! il n'y a pas à discuter : la donnée est constante, toute modification de son état est interdite; et le compilateur sera là pour s'assurer que cette contrainte sera respectée. Point - Barre.

    Dés lors, en tant que développeur de la fonctionnalité, si je peux imposer l'immuabilité à une donnée locale (en créant une constante), au nom de quoi, quelle règle pourrait m'imposer d'attendre d'être dans le corps de ma fonction pour définir une donnée locale supplémentaire à laquelle imposer l'immuabilité à partir d'un paramètre que j'aurais reçu (quelle que soit la manière dont il m'a été transmis), alors que j'aurais "tout aussi bien pu" imposer cette immuabilité directement au paramètre que je reçois, ce qui m'aurait éviter de définir une donnée locale supplémentaire en "remplacement" de ce qui sera -- de toutes manières -- aussi considéré comme une donnée locale

    J'ai beau chercher, je ne vois aucune raison, aucune règle qui m'imposerait de travailler sous une forme proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    void foo(int param){
        int const copy{param};
        /* je dois veiller à n'utiliser que copy et à ne pas utiliser param pour garantir la constance */
    }
    alors que j'aurais aussi bien pu avoir un code proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    void foo(int const param){
        /* il est clair dés le départ que param ne pourra pas être modifié ici */
    }
    Qui aurait apporté la garantie d'immuabilité dés le départ.

    Mais peut-être ai-je loupé quelque chose
    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

  13. #13
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2011
    Messages
    739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : Juin 2011
    Messages : 739
    Points : 3 627
    Points
    3 627
    Par défaut
    On ne dit pas que const est inutile dans les paramètres, on dit que c'est inutile de le faire pour la déclaration qui se trouve dans le .h puisque cela n'apporte rien.

    Je t'invite à relire le commentaire #8.

  14. #14
    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
    Nous sommes d'accord sur le fait que cela n'apporte rien à l'utilisateur. Et je n'ai jamais prétendu le contraire.

    Mais cela fait plusieurs interventions que je le répète je m'en fous royalement que cela n'apporte rien de plus à l'utilisateur. Ce qui m'importe, c'est ce que cela peut m'apporter à moi, en tant que développeur de la fonction.

    Or, en tant que développeur d'une fonction, moi, ca me chatouille aux omoplates de la déclarer (dans le fichier d'en-tête) sous la forme de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    #ifndef HEADER_HPP
    #define HEADER_HPP
    void foo(int framerate);
    void bar(double enlapsedTime);
    #endif
    et de l'implémenter sous la forme de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    void foo(int const framerate){
        /* si je modifie framerate ici, je fausse mes calculs */
    }
    void bar(double const enlapsedTime){
       /* si je modifie enlapsedTime ici, je fauce mes calculs */
    }
    ou, plus vraisemblablement, sous une forme qui serait proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    void foo(int framerate){
        /* si je modifie framerate ici, je fausse mes calculs, donc je crée une constante */
       int const copy{framerate};
       /* et je veille bien à n'utiliser que copy ici */
    }
    void bar(double const enlapsedTime){
        /* si je modifie enlapsedTime ici, je fausse mes calculs, donc je crée une constante */
       int const copy{enlapsedTime};
       /* et je veille bien à n'utiliser que copy ici */
    }
    afin de respecter un prototype qui n'aurait pas profiter de l'occasion qui lui était donnée de rendre l'interdiction de modifier le paramètre explicite
    1. D'abord, parce que cela m'oblige à créer une variable supplémentaire alors qu'elle est inutile;
    2. Ensuite parce que cela m'interdit d'utiliser le paramètre reçu pour l'usage auquel il est normalement clairement destiné;
    3. Et enfin, parce que, dans ma grande sagesse, je me rend compte que je ne vaux pas mieux que les autres : je suis un imbécile distrait qui ne manquera pas de faire une connerie si je m'en laisse l'occasion. Le malheur voulant que je n'ai aucune raison d'espérer que celui qui modifiera mon code fera mieux que moi sur ce coup là.

    Il me semble donc tout à fait cohérent de m'appuyer sur le compilateur pour que -- quoi qu'il puisse se passer -- l'interdiction de modifier le paramètre fasse "partie de l'ADN" de ma fonction.

    De cette manière, même s'il ne devait plus rester que le prototype de la fonction et la paire d'accolades, parce que celui qui viendra "après moi" a envisagé un algorithme bien plus efficace, il n'y aurait que "beaucoup moins de risques" (à défaut de pouvoir dire "aucun risque") qu'il décide de modifier framerateou enlapsedTime.

    EDIT
    L'un dans l'autre, il est bon de se rappeler qu'il y a systématiquement trois "parties prenantes" sur un projet:
    1. Celui qui développe une fonction "parce qu'elle sera utile"
    2. Celui qui utilise une fonction "pace qu'elle prend en charge (une partie de) ses besoins" et
    3. Le compilateur, qui s'assure de la validité du code pour générer l'exécutable.

    Même si -- a priori -- l'utilisateur n'a aucun intérêt à aller voir du coté de l'implémentation, le code s'adresse systématiquement au trois intervenants, et gagne systématiquement à profiter au maximum de la rigueur du compilateur.

    Pourquoi faudrait il écarter une possibilité qui nous permet de profiter de cette rigueur au seul prétexte que "cela n'apporte rien à l'utilisateur"
    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

  15. #15
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2011
    Messages
    739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : Juin 2011
    Messages : 739
    Points : 3 627
    Points
    3 627
    Par défaut
    Je comprends pas ce que vient faire le 3ème code. const n'a aucun impacte sur le prototype pour les paramètres pris par valeur. C'est tout à valide de mettre dans une déclaration un paramètre non const puis le mettre const dans la définition.

  16. #16
    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
    Mais cela fait plusieurs interventions que je le répète je m'en fous royalement que cela n'apporte rien de plus à l'utilisateur. Ce qui m'importe, c'est ce que cela peut m'apporter à moi, en tant que développeur de la fonction.
    Et moi je m'en bats les cahuets de ce que tu fais dans l'implémentation tant que je sais comment l'utiliser.
    Tu peux répéter une énième fois ta prose, ca n'y changera rien.
    Pourquoi faudrait il écarter une possibilité qui nous permet de profiter de cette rigueur au seul prétexte que "cela n'apporte rien à l'utilisateur"
    Au hasard parce que l'utilisateur est ma cible ?
    Tout comme je pense mon interface publique etc pour lui. Le reste est un détail d'implémentation dont il n'a rien à foutre où je fais ce qu'il faut pour rendre les services voulus et attendus.

    Et même s'il m'arrive de mettre le const dans le prototype pour un paramètre copié, entre autre parce que c'est copié /collé entre header et implémentation, ca n'en reste pas moins absolument inutile.

    Alors pour répondre au message original
    Citation Envoyé par Seabirds Voir le message
    Mon premier réflexe a été de me dire que le const devant des arguments passés par copies c’était superflu
    A raison puisque oui c'est redondant et donc inutile et n'apporte aucune information supplémentaire sur ce que les variables que je passe en paramètre deviennent.

    mais en allant fouiller j'ai vu qu'il y avait tout un débat la dessus.
    Sur internet tout est sujet à débat hélas... Ce sujet ne fait pas exception.
    Mais franchement c'est de l'enculage de mouches
    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.

  17. #17
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Or, en tant que développeur d'une fonction, moi, ca me chatouille aux omoplates de la déclarer (dans le fichier d'en-tête) sous la forme de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    #ifndef HEADER_HPP
    #define HEADER_HPP
    void foo(int framerate);
    void bar(double enlapsedTime);
    #endif
    et de l'implémenter sous la forme de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    void foo(int const framerate){
        /* si je modifie framerate ici, je fausse mes calculs */
    }
    void bar(double const enlapsedTime){
       /* si je modifie enlapsedTime ici, je fauce mes calculs */
    }
    Avec l'habitude, ça chatouillera moins.

  18. #18
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    393
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 393
    Points : 684
    Points
    684
    Par défaut
    Si la norme a explicitement decide que le cv n'etait pas pris en compte, c'est qu'il y a des raisons.

    Un exemple concret de probleme si le cv etait strict. Imaginons qu'on veut ecrire une fonction qui retourne l'element au milieu d'une collection (ce qu'on fait dans beaucoup d'algos dans les approches divide and conquer).

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    template<typename Iterator>
    Iterator pivot(Iterator const first, Iterator const last);
    On va avoir 2 implementations possible, selon si c'est un random iterator ou pas.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    template<RandomAccessIterator Iterator> // concept powaaaaa
    Iterator pivot(Iterator const first, Iterator const last) {
        return first + std::distance(first, last) / 2;
    }
     
    template<PasRandomAccessIterator Iterator> // concept faillllll
    Iterator pivot(Iterator const first, Iterator const last) {
        Iterator localFuckingCopy { first };
        std::advance(localFuckingCopy, std::distance(localFuckingCopy, last) / 2);
        return localFuckingCopy;
    }
    Et si tu regardes les propositions d'implementation de la majorite des algos standard sur cppreference, ils s'amusent tous a modifier le parametre first dans le for.

    On en arrive a un probleme d'implementation si le cv eststrict.
    • soit on met const et on est oblige de faire une copie (inutile puisque c'est deja une copie)
    • soit on ne met pas const dans le prototype, et on impose a l'utilisateur de la fonction et a toutes les implementations de ne pas etre const.


    (On aurait le meme probleme avec des fonctions virtuelles)

    La norme autorise a ne pas mettre const dans l'interface et mettre const dans les implementations qu'on veut. Ce n'est pas pour rien. Ca ne sert a rien d'etre plus rigide que le necessaire.

  19. #19
    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 jo_link_noir Voir le message
    Je comprends pas ce que vient faire le 3ème code. const n'a aucun impacte sur le prototype pour les paramètres pris par valeur. C'est tout à valide de mettre dans une déclaration un paramètre non const puis le mettre const dans la définition.
    Mais il est tout aussi valide de placer placer le const directement dans le prototype

    Or, une chose est sur pour moi, en tant que développeur de foo et de bar : si j'augmente la valeur de framerate (dans le corps de foo) ou celle de enlapsedTime (dans le corps de bar), je fausse mes calculs et j'obtiendrai un résultat qui me donnera l'impression de tourner au ralenti.

    A l'inverse, si je diminue ces valeurs (respectivement dans le code de foo ou de bar), je fausse aussi mes calculs et j'aurai un résultat qui me donnera l'impression d'un accéléré.

    Ce sont deux situations que je ne peux pas admettre en tant que développeur, si bien que je veux pouvoir garantir qu'elles n'arriveront jamais. Et, par chance, le compilateur est là pour m'aider à faire respecter la règle simple : frameRate (respectivement enlapsedTime) ne sera jamais modifié.

    Et si tu te demande pourquoi je voudrais imposer cette règle, dis toi que c'est uniquement à cause de la loi de finagle; je pars du principe que le type qui lira (ou pire, devra modifier) mon code est un imbécile distrait. (Mais rassures toi, je me compte dans le lot ).

    Citation Envoyé par Bousk Voir le message
    Et moi je m'en bats les cahuets de ce que tu fais dans l'implémentation tant que je sais comment l'utiliser.
    Mais, ce que tu as l'air d'oublier, c'est que le prototype qui se trouve dans ton fichier d'en-tête, il fait partie de toutes les unités de compilation dans lesquelles il est inclut de manière directe ou indirecte!

    Et, que, du coup, ce prototype -- dont nous sommes bien d'accord qu'il n'apporte aucune information supplémentaire pertinente à l'utilisateur de la fonction -- n'est pas à l'usage exclusif de l'utilisateur de la fonction.

    L'un des destinataires principaux de ton code (de tout ton code, quel que soit le fichier dans lequel il se trouve ai-je envie d'écrire), et qui apparaîtra -- dans l'ordre logique des choses -- sans doute même avant que l'utilisateur ne pose les yeux sur le prototype, c'est ... le compilateur.

    C'est à dire le meilleur ami de toute personne susceptible -- entre autres -- de modifier l'implémentation de ma fonction. Principalement, parce que si celui qui tentera de modifier l'implémentation de ma fonction essaye de faire quelque chose qui n'aurait pas lieu d'être (comme modifier la valeur de frameRate ou de enlapsedTime), le fait de déclare la donnée en question comme constante donne une chance au compilateur d'exprimer son désaccord.
    Tu peux répéter une énième fois ta prose, ca n'y changera rien.
    Mais, en attendant, je n'ai toujours pas eu de réponse à ma question:

    Citation Envoyé par moi
    Pourquoi devrais-je attendre d'être dans l'implémentation d'une fonction pour imposer la constance à une donnée recue par copie en paramètre
    Au hasard parce que l'utilisateur est ma cible ?
    Parce que l'utilisateur est une de tes cibles. Et, manque de pot, c'est la seule cible dont tu ignore tout!!!

    Mais tu oublie une autre de tes cibles, et, quelque part, ta cible principale lorsque tu agis en tant que développeur : le compilateur.

    Car c'est lui qui doit s'assurer que ton code est valide avant d'essayer de générer le code binaire de l'exécutable


    Tout comme je pense mon interface publique etc pour lui. Le reste est un détail d'implémentation dont il n'a rien à foutre où je fais ce qu'il faut pour rendre les services voulus et attendus.
    Bien sur que ce n'est qu'un détail d'implémentation. Je n'ai jamais prétendu le contraire!

    Mais, cela a beau être un détail d'implémentation, c'est un invariant que tu peux vouloir imposer à ta fonction.

    Et même s'il m'arrive de mettre le const dans le prototype pour un paramètre copié, entre autre parce que c'est copié /collé entre header et implémentation, ca n'en reste pas moins absolument inutile.
    inutile pour l'utilisateur, encore une fois... (et je n'ai jamais prétendu le contraire)

    Et, d'un autre coté, si cela n'apporte effectivement rien à l'utilisateur, je pourrais faire remarquer cela ne lui coute rien non plus, alors que cela peut apporter énormément au compilateur

    Mais, parfaitement justifié pour le développeur et / ou le compilateur.

    Alors pour répondre au message original

    A raison puisque oui c'est redondant et donc inutile et n'apporte aucune information supplémentaire sur ce que les variables que je passe en paramètre deviennent.
    Bis repetitas...
    superflus pour l'utilisateur, encore une fois... (et je n'ai jamais prétendu le contraire)

    Mais, parfaitement justifié pour le développeur et / ou le compilateur.
    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

  20. #20
    Membre expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2011
    Messages
    739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : Juin 2011
    Messages : 739
    Points : 3 627
    Points
    3 627
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Mais, en attendant, je n'ai toujours pas eu de réponse à ma question:

    Pourquoi devrais-je attendre d'être dans l'implémentation d'une fonction pour imposer la constance à une donnée recue par copie en paramètre
    Au hasard parce que l'utilisateur est ma cible ?
    Parce que c'est le seul endroit où cette variable est susceptible de changer. Et non, l'utilisateur n'est pas la cible de l'implémentation.

    Citation Envoyé par koala01 Voir le message
    Mais tu oublie une autre de tes cibles, et, quelque part, ta cible principale lorsque tu agis en tant que développeur : le compilateur.

    Car c'est lui qui doit s'assurer que ton code est valide avant d'essayer de générer le code binaire de l'exécutable
    Ce qui rend le const utile uniquement dans la définition puisque c'est la partie à destination du développeur.

    Citation Envoyé par koala01 Voir le message
    Et, d'un autre coté, si cela n'apporte effectivement rien à l'utilisateur, je pourrais faire remarquer cela ne lui coute rien non plus, alors que cela peut apporter énormément au compilateur
    Si, du bruit. Tout bruit à un coût, même minime. Quant au compilateur, il se fiche totalement du const sur les paramètres pris par valeur dans un prototype.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Django: Help view avec un argument passé par une url
    Par 123alban2007 dans le forum Django
    Réponses: 0
    Dernier message: 13/11/2015, 16h21
  2. conteneur passé par copie: reception bizarre.
    Par Krishna dans le forum SL & STL
    Réponses: 2
    Dernier message: 01/03/2009, 21h18
  3. Erreur sur mon constructeur par copie
    Par beegees dans le forum C++
    Réponses: 8
    Dernier message: 02/04/2008, 21h58
  4. Question sur les variables passées par URL
    Par cotlod dans le forum Langage
    Réponses: 7
    Dernier message: 11/10/2006, 01h04
  5. Réponses: 2
    Dernier message: 27/07/2006, 19h50

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