Const sur argument passé par copie

Version imprimable

16/08/2018, 19h15
Seabirds

Const sur argument passé par copie

Salut,

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

Citation:

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 ?
16/08/2018, 19h57
Bousk

Superflu et inutile dans le prototype.
Dans l'implementation ca peut avoir un interet.
16/08/2018, 21h44
jo_link_noir

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.
18/08/2018, 16h40
koala01

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:

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.
18/08/2018, 18h03
mintho carmo
Citation:

Envoyé par koala01

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:

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.
18/08/2018, 19h28
koala01
Citation:

Envoyé par mintho carmo

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

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 :D ) 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

Code:

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:

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

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:

1 2 3 4 5 void bar(){ const int size{53}; /* ... */ }
:question:

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

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) :question:

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

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 :question:

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 :question: parce qu'une valeur copiée devra forcément être modifiée :question: 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

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 :question:

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

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).
18/08/2018, 22h45
Pyramidev

Citation:

Envoyé par koala01

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 :question: parce qu'une valeur copiée devra forcément être modifiée :question: 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.
19/08/2018, 00h30
mintho carmo
Citation:

Envoyé par koala01

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:

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.
19/08/2018, 00h46
koala01

Citation:

Envoyé par Pyramidev

<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 ;)
19/08/2018, 03h45
Bousk

Citation:

Envoyé par koala01

"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 ? :weird:
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.
19/08/2018, 15h56
koala01
Citation:

Envoyé par Bousk

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.

Citation:

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 ? :weird:

Et pourquoi attendre d'être dans le corps de la fonction pour rajouter cette constante :question:

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).

Citation:

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
19/08/2018, 18h20
koala01
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

Citation:

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 :question:

J'ai beau chercher, je ne vois aucune raison, aucune règle qui m'imposerait de travailler sous une forme proche de
Code:

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:

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 :question:
19/08/2018, 21h13
jo_link_noir

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.

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:

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:

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:

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

D'abord, parce que cela m'oblige à créer une variable supplémentaire alors qu'elle est inutile;
Ensuite parce que cela m'interdit d'utiliser le paramètre reçu pour l'usage auquel il est normalement clairement destiné;
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:

Celui qui développe une fonction "parce qu'elle sera utile"
Celui qui utilise une fonction "pace qu'elle prend en charge (une partie de) ses besoins" et
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" :question:

19/08/2018, 23h07
jo_link_noir

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.
19/08/2018, 23h38
Bousk

Citation:

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. :weird:
Tu peux répéter une énième fois ta prose, ca n'y changera rien.

Citation:

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

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.

Citation:

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:roll:

Citation:
Envoyé par koala01
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:

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:

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.

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:

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:

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.

20/08/2018, 00h22
koala01

Citation:

Envoyé par jo_link_noir

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

Et moi je m'en bats les cahuets de ce que tu fais dans l'implémentation tant que je sais comment l'utiliser. :weird:

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.

Citation:

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 :question:

Citation:

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 ;)

Citation:

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.

Citation:

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.

Citation:

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.
20/08/2018, 03h44
jo_link_noir

Citation:

Envoyé par koala01

Mais, en attendant, je n'ai toujours pas eu de réponse à ma question:

Citation:

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

Citation:

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

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

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.
20/08/2018, 11h24
Médinoc

Pour moi (toujours dans le cas de paramètres passés par copie), ajouter le const dans le prototype, c'est exposer un détail d'implémentation.
20/08/2018, 13h13
ac_wingless

La discussion suppose qu'il est clair pour l'utilisateur de la fonction que le paramètre est passé par copie, et les avis des deux camps se partagent une fois ceci admis.
Dans le cas où le type du paramètre est imposé, on peut avoir une ambiguité sémantique: on a tous vu dans du code imposé des types vieux du genre sI32_LPW_mppr_DOUBLE_HANDLE, caché derrière trois niveaux de typedef dépendant de la cible de compilation. Pour moi, utilisateur, j'aimerais bien savoir que telle fonction ne va pas me changer la valeur de mon paramètre de type alacon dont je ne sais rien, en tout cas dont je ne suis pas sûr que ce ne soit pas une référence macromagique. Je ne suis pas sûr non plus que la version 2.35b de la bibliothèque externe qui sortira dans deux ans ne va pas me transformer ce handle bizarre en référence au quatrième des 7 typedef chainés.

Je sais bien que la question en tête de cette discussion suppose qu'on passe bien par copie, donc le cas que je cite est limite hors sujet, mais le principe de renseigner l'utilisateur sur les contraintes imposées sur un paramètre par une fonction que vous écrivez n'est pas du bruit.
20/08/2018, 13h45
mintho carmo
Citation:

Envoyé par ac_wingless

la bibliothèque externe qui sortira dans deux ans ne va pas me transformer ce handle bizarre en référence au quatrième des 7 typedef chainés.

Ou en rvalue-reference et donc s'attendre à ce que la fonction prenne la responsabilité de l'objet passé à la fonction et donc que const serait un gros problème...

On ne peut pas non plus garantir tous les changements qui peuvent arriver. On part d'un contrat proposé et on implémente en fonction de ça. On peut prévoir quelques rupture de contrats (*), mais pas tous les cas possibles. C'est à celui qui rompt le contrat de vérifier que le nouveau contrat est respecté partout.

(*) au pire, tu peux mettre un static_assert + traits pour mettre des garanties sur les types. Mais qui s'amuse a faire ca ? On le fait par exemple avec des templates, où par définition le type passé en argument doit respecter un certain contrat imposé par la fonction. Mais on ne va pas le faire sur un alias de type.

Sérieusement, qui s'amuserait à changer un alias de type d'une valeur en pointeur ou référence ???
Code:

1 2 3 4 5 6 7 using MyToto = Object; MyToto foo() { MyToto toto; return toto; }
Celui qui change "Object" en "Object*" ou "Object&", son problème ne sera probablement pas les const/non const dans les fonctions, mais les déclarations. Je classerais ce changement dans la catégorie "erreurs monumentales".

Citation:

Envoyé par mintho carmo

(*) au pire, tu peux mettre un static_assert + traits pour mettre des garanties sur les types. Mais qui s'amuse a faire ca ? On le fait par exemple avec des templates, où par définition le type passé en argument doit respecter un certain contrat imposé par la fonction.

Attention, static_assert est généralement un mauvais substitut aux concepts du C++20, car std::is_invocable_v et ses copains de <type_traits> ignorent les static_assert qui se trouvent à l'intérieur des modèles de fonction.
En attendant les concepts du C++20, il faut subir std::enable_if_t.

Par exemple, voici un code qui compile en C++17 :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 #include <type_traits> struct BadFunctor { template<class T> void operator()(T x) { static_assert( std::is_pointer_v<T> ); } }; static_assert( std::is_invocable_v<BadFunctor, int*> == true ); // OK static_assert( std::is_invocable_v<BadFunctor, int> == true ); // WHAT?! struct GoodFunctor { template<class T, std::enable_if_t<std::is_pointer_v<T>, int> = 0> void operator()(T x) { static_assert( std::is_pointer_v<T> ); } }; static_assert( std::is_invocable_v<GoodFunctor, int*> == true ); // OK static_assert( std::is_invocable_v<GoodFunctor, int> == false ); // OK #include <iostream> int main() { #ifdef __GNUC__ std::cout << "GCC version: " << __VERSION__ << "\n\n"; #endif return 0; }

20/08/2018, 15h27
mintho carmo

(merci du rappel)
20/08/2018, 18h27
jo_link_noir
Citation:

Envoyé par ac_wingless

la bibliothèque externe qui sortira dans deux ans ne va pas me transformer ce handle bizarre en référence au quatrième des 7 typedef chainés.

Ce qui ne changera rien, const sera ignoré ici aussi puisque appliqué sur la référence et non sur la valeur référencé.
Code:

1 2 3 4 5 using reference = int&; int i = 0; reference const r = i; // const r = 3; // modification de la valeur car r est de type `int&`
Donc non, il n'y a pas de garantie, pire encore, tu as l'impression que le paramètre ne pourra pas être modifié.
21/08/2018, 19h05
koala01

Citation:

Envoyé par jo_link_noir

Parce que c'est le seul endroit où cette variable est susceptible de changer.

Nous sommes bien d'accord... Mais, pourquoi devrait on attendre d'être "au plus proche" de l'endroit où la variable est susceptible de changer pour imposer une restriction destinée à l'interdire :question:

Au contraire, plus on tarde à imposer cette restriction, plus on court le risque qu'un "imbécile distrait" la supprime "par mégarde" en effaçant le bloc de code qu'il s'apprête à modifier (ou qu'il décide "par mégarde" d'en modifier la valeur avant que la restriction ne soit imposée).

Or, le prototype d'une fonction est sans doute la partie du code la plus stable, qui est modifiée le moins souvent.

Je suis donc tout à fait d'accord que cela ne me garantira pas que la restriction que je veux imposer à l'usage de ma donnée (dans l'implémentation) ne sera jamais levée par mégarde. Mais cela réduit quand même très largement le risque, ne serait-ce parce qu'elle est mise en place dés que l'on passe l'accolade ouvrante du corps de la fonction.

Citation:

Et non, l'utilisateur n'est pas la cible de l'implémentation.

Je n'ai jamais dit le contraire non plus, que je sache ;)

Citation:

Ce qui rend le const utile uniquement dans la définition puisque c'est la partie à destination du développeur.

Nous sommes bien d'accord là dessus aussi, mais cela ne justifie toujours pas -- à mon sens -- qu'il faille attendre de s'adresser "exclusivement au développeur" pour fournir une information sous prétexte... "qu'elle n'est utile qu'au développeur" (et, accessoirement, au compilateur qu'il ne faut pas oublier non plus ;) )

Citation:

Si, du bruit. Tout bruit à un coût, même minime.

Quel bruit :question: Quel cout a-t-il réellement pour l'utilisateur :question:

J'ai bien conscience que nos avis sont beaucoup trop divergents pour que nous puissions nous mettre d'accord (que ce soit parce que je finirais par adhérer à ton point de vue ou l'inverse).

Mais même si on se met à parler de la "surcharge cognitive" que l'on peut imposer à l'utilisateur au travers de l'interface qu'on lui fournit, je crois que celle imposée par un const que l'on pourrait juger "inutile du point de vue de l'utilisateur" est très loin dans la liste des priorités des choses à corriger
21/08/2018, 22h31
jo_link_noir

Citation:

Envoyé par koala01

Au contraire, plus on tarde à imposer cette restriction, plus on court le risque qu'un "imbécile distrait" la supprime "par mégarde" en effaçant le bloc de code qu'il s'apprête à modifier (ou qu'il décide "par mégarde" d'en modifier la valeur avant que la restriction ne soit imposée).

Encore une fois, tu ajoutes des intermédiaires qui n'existent pas.

Citation:

Envoyé par koala01

Mais cela réduit quand même très largement le risque, ne serait-ce parce qu'elle est mise en place dés que l'on passe l'accolade ouvrante du corps de la fonction.

C'est ce qu'on dit depuis le début. Il n'y a que toi qui imposes un prototype absolument identique pour la déclaration et la définition alors que ce n'est pas nécessaire: le cv ne fait pas partie de la signature de la fonction. On en revient à ce qui est dit depuis le début: inutile dans .h, au bon vouloir du développeur dans le cpp.
21/08/2018, 23h01
koala01

Citation:

Envoyé par jo_link_noir

Encore une fois, tu ajoutes des intermédiaires qui n'existent pas.

sur combien de projets (pro et privé) as tu participé ces cinq dernières années :question:

Quelle est -- selon toi -- la proportion de code "originale" qui n'a jamais été modifiée pour ces projets :question:

A quelle vitesse les équipe de devs de ces projets changeaient-elles :question:

S'il fallait faire une moyenne sur les projets (auxquels tu as participé) qui sont en développement depuis plus de cinq ans (quand tu as intégré l'équipe) du nombre de développeurs qui ont participé, à ton avis, quel nombre atteindrions nous :question:

Si nous devions revoir l'historique de tous les fichiers, quelle proportion aurait été modifiée ne serait-ce que par mettons ... cinq développeurs différents :question:

Au vu de ces chiffres, comment peux tu sincèrement croire que je rajoute des intermédiaires qui n'existent pas en pensant au développeur qui passera "derrière moi" :question:
21/08/2018, 23h42
jo_link_noir

Je ne parle des intermédiaires au niveau des personnes, mais au niveau de l'écriture des variables pour les mettre à const en me basant sur ton exemple page précédente () où, pour une raison que je n'ai toujours pas saisie, tu ne veux pas avoir de paramètre const sous prétexte qu'ils ne le sont pas dans le .h.

Si c'est la différence d'écriture entre le .h et .cpp qui t'importune, dit le clairement parce que depuis un moment je ne parle plus du bénéfice de const, mais de ne pas le mettre là où il est inutile.
22/08/2018, 01h13
koala01

Citation:

Envoyé par jo_link_noir

<snip>pour une raison que je n'ai toujours pas saisie, tu ne veux pas avoir de paramètre const sous prétexte qu'ils ne le sont pas dans le .h.

Je reconnais sans honte que la raison est tout -- sans doute -- à fait idiote, mais je préfères fournir l'implémentation de mes fonctions en utilisant le prototype tel qu'il apparaît dans mon interface.

Et, comme nous sommes bien d'accord que les gouts et les couleurs ne se discutent pas, je vais justifier quelque peu cette raison: j'estimes que cela facilite le travail lorsqu'il s'agit de rechercher l'endroit du code où l'implémentation se trouve.

Avec un langage qui ne permettrait pas la surcharge de fonctions (comme C, par exemple ), je pourrais peut être concevoir que cela ait moins d'importance, parce que le seul nom de la fonction est "suffisamment discriminant" en cas de recherche (et encore ! en basant une recherche sur le nom de la fonction, on se retrouve avec une déclaration, une implémentation et ... N appels).

Mais dois-je te rappeler le nombre de surcharges de fonctions que l'on retrouve ne serait-ce que dans la classe std::basic_string :question:

Dois-je te rappeler le nombre d'implémentations d'une fonction parmi lequel tu devras "chercher la bonne" si tu base ta recherche exclusivement sur le nom de la fonction :question:

Nous sommes bien d'accord qu'il y a tout un tas de raisons qui font que j'ai choisi un très mauvais exemple.

Mais il expose malgré tout clairement le problème : Quand tu as une fonction qui présente N surcharges différentes, tu auras toujours plus facile de faire une recherche sur l'ensemble du prototype (que tu trouveras sans doute dans le fichier d'en-tête), en prenant en compte les éventuels CV-qualifiers qui apparaissent à cette occasion que si tu avais décidé de ... supprimer un des CV-qualifiers de ce prototype sous prétexte... "qu'il n'apporte aucune information pertinente à l'utilisateur de la fonction".

Au risque d'exprimer un manque de foi flagrant envers les développeurs des EDI, je me dis que la concordance des prototypes aidera sans aucun doute à retrouver l'implémentation correcte d'une fonction quand on décide d'utiliser la fonctionnalité "go to implementation" (ou que, à défaut, cela ne rendra pas les choses plus compliquées).

Si bien que, l'un dans l'autre, j'ai beau admettre que cela n'apporte rien à l'utilisateur de ma fonction, j'ai beau même aller jusqu'à admettre que cela apporte sans doute une surcharge cognitive (mais bon, on ne parle pas de la sucharge cognitive du fait inverse, lorsque l'on doit rechercher l'implémentation :D ), il n'en reste pas moins que je trouve plus d'avantages que d'inconvénients au fait de définir -- y compris dans le fichier d'en-tête -- un paramètre comme constant quelle que soit la manière dont il a été transmis.
22/08/2018, 14h10
mintho carmo

Citation:

Envoyé par koala01

j'estimes que cela facilite le travail lorsqu'il s'agit de rechercher l'endroit du code où l'implémentation se trouve.

Ctrl (ou Cmd) + clic gauche sur le nom de la fonction.

De rien.

Citation:

Envoyé par koala01

Au risque d'exprimer un manque de foi flagrant envers les développeurs des EDI

Homme de peu de foi.

Au moins, eux, ils se rappellent que faire une recherche textuelle en utilisant la déclaration d'une fonction pour trouver l'implémentation peut facilement échouer, si le dev change le cv, change le nom du parametres, qu'il y a des paramètres par défaut, s'il utilise des espaces de noms, s'il y a le scope de la classe, s'il utilise des alias de type, ou change simplement la position des espaces et retour à la ligne...

Ce n'est pas pour rien que QtCreator ou MSVC par exemple utilisent Clang pour parser le texte.
22/08/2018, 15h28
koala01

Citation:

Envoyé par mintho carmo

Ctrl (ou Cmd) + clic gauche sur le nom de la fonction.

De rien.

Et quand on utilise un "vieux truc" comme vim gedit ou emacs :question:

Citation:

Homme de peu de foi.

Hé oui, mais je l'ai toujours dit ;)
22/08/2018, 17h37
Bktero

Citation:

Envoyé par koala01

Et quand on utilise un "vieux truc" comme vim gedit ou emacs :question:

[TROLL]
Et tu vas aussi dire qu'il faut respecter 80 colonnes par ligne pour les vieux écrans ? :salive:

[/TROLL]

:dehors:
22/08/2018, 19h01
koala01

Je respecte effectivement autant que possible les 80 colonnes, non pas forcément pour les vieux écrans, mais surtout parce que je trouve que c'est une limite "raisonnable".

Et je n'en ferai pas une maladie si je dois écrire un ligne de code qui tient sur 90 colonnes :D

Ceci dit, même à titre professionnel, il m'arrive très souvent de préférer lancer un éditeur de textes "un peu évolué" comme ceux que j'ai cités ou comme notepad++, sous windows) et d'avoir une simple ligne de commandes pour exécuter les tâches "répétitives" (compilation, tests, commit vers le système de gestion de versions concurrentes, ...)

Et ce sera d'autant plus le cas si je dois pouvoir assurer "une certaine portabilité" au projet sur lequel je travaille.

Quoi, serais-je une sorte d'alien à travailler de la sorte :question:
23/08/2018, 17h41
Dutiona
Petit rajout à cette discussion pour ceux qui utilisent des compilateurs un peux Sioux (et surtout non conforme comme ceux d'AIX ou d'Oracle sur Solaris) :
Par exemple, Sun CC est non conforme sur ce point précis : un prototype où il y a un const par valeur est différent d'un prototype où il y a une valeur non const.
Donc ce code-la :
Code:

1 2 3 4 5 6 7 8 9 10 void foo(int a); void foo(const int a) { } int main() { foo(0); }
On a une erreur de link car 2 symboles différents ont été générés. Il faut rajouter le const dans la déclaration du prototype.

C'est la raison pour laquelle on peut trouver des codes un peu "nazi" sur la cohérence entre la déclaration et la définition dans du legacy qui a eu à tourner sur ces platformes.

En pratique je préfère ne jamais le préciser dans la déclaration et je l'utilise très peu dans la définition.
28/08/2018, 11h15
Luc Hermitte

Citation:

Envoyé par koala01

Et quand on utilise un "vieux truc" comme vim gedit ou emacs :question:

`:GOTOIMPL` :)
Après, je ne sais plus si mon plugin gère le cas où il y a une cv-différence entre la déclaration et la définition des fonctions.

Sinon, comme pour beaucoup, savoir si le paramètre formel (qui n'est qu'une sorte de variable locale auto alimentée) est modifié ou non ne regarde pas le code qui utilise la fonction. Ce n'est qu'un détail d'implémentation pour faciliter le boulot du développeur et des mainteneurs futurs de la fonction.

Après, je constate aussi une forte préférence à avoir exactement la même signature (aux sauts de lignes près, et encore) entre déclaration pure (.h) et définition (.cpp). Sans parler des recopies pour frameworks tels que SWIG. Essentiellement parce que c'est plus simple à maintenir.

Même si j'abuse de const dans les (vraies) variables locales, j'avoue ne pas m'en servir dans les déclarations des paramètres formels. Une question d'habitude je dirai. Plus le fait que j'oriente avant tout les signatures vers les utilisateurs. Et quand je me repose volontairement sur l'élision de copie, je le signale dans les commentaires de la fonction.