Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char*
argv[].
Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char*
argv[].
Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char*
argv[].
En c65d17$7hd$, Marc Boyer va escriure:Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char*
argv[].
La déclaration "correcte" est
char * const argv[]
<DIGRESSION>
Pour des raisons de compatibilité avec l'existant, l'officielle n'a pas le
const. Mais la norme C dans son texte refuse l'autorisation de modifier les
éléments du tableau: 5.1.2.2.1p2, en partie:
-- The parameters *argc* and *argv* and the strings pointed to by the
*argv* array shall be modifiable by the program, and retain their last-
stored values between program startup and program termination.
Par élimination, tout est modifiable, sauf les éléments du tableau argv
original. Autrement sit, si tu veux modifier les éléments de argv[], il faut
d'arbord copier le tableau ailleurs, faire les modifications que tu veux, et
ensuite réaffecter argv vers ta copie locale.
</DIGRESSION>
[SNIP]
Mais à partir du moment où il y a un const dans le type,
GCC C devient féroce, et refuse de convertir un tableau non modifiable
(argv) en tableau modifiable (ton paramètre), même si dans le même temps tu
augmentes la contrainte sur les éléments pointés (modifiables selon la
norme, non modifiés selon ton prototype).
D'autre part, il y a la tentative d'augmenter la contrainte sur les chaînes
pointées. Ici, je pense que C et C++ divergent, donc tout ce que j'écris
peut ne pas être vrai en C++.
En C, donc, la règle sur const signifiant "ne sera pas modifié" s'applique
uniquement au paramètre lui-même, pas aux composants à partir desquels est
construit son type.
Détail: 6.3.2.2/6.5.2.2 Function calls, par. 2, en partie:
Each argument shall have a type such that its value may be assigned to
an object with the unqualified version of the type of its corresponding
parameter.
Ce qui renvoie vers les affectations: 6.3.16.1/6.5.16.1 Simple assignment,
par.1, en partie:
- both operands are pointers to qualified or unqualified versions of
compatible types, and the type pointed to by the left has all the
qualifiers of the type pointed to by the right;
Il faut donc s'en remettre aux règles de compatibilité de types pour voir si
on peut ajouter des qualificateurs sur les sous-éléments. Et là, surprise,
si tu changes les qualificateurs, ce n'est plus compatible: 6.5.4.1/6.7.5.1
Pointer declarators, par.2:
For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types.
Ce qui explique les râleries de GCC C.
En c65d17$7hd$1@news.cict.fr, Marc Boyer va escriure:
Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char*
argv[].
La déclaration "correcte" est
char * const argv[]
<DIGRESSION>
Pour des raisons de compatibilité avec l'existant, l'officielle n'a pas le
const. Mais la norme C dans son texte refuse l'autorisation de modifier les
éléments du tableau: 5.1.2.2.1p2, en partie:
-- The parameters *argc* and *argv* and the strings pointed to by the
*argv* array shall be modifiable by the program, and retain their last-
stored values between program startup and program termination.
Par élimination, tout est modifiable, sauf les éléments du tableau argv
original. Autrement sit, si tu veux modifier les éléments de argv[], il faut
d'arbord copier le tableau ailleurs, faire les modifications que tu veux, et
ensuite réaffecter argv vers ta copie locale.
</DIGRESSION>
[SNIP]
Mais à partir du moment où il y a un const dans le type,
GCC C devient féroce, et refuse de convertir un tableau non modifiable
(argv) en tableau modifiable (ton paramètre), même si dans le même temps tu
augmentes la contrainte sur les éléments pointés (modifiables selon la
norme, non modifiés selon ton prototype).
D'autre part, il y a la tentative d'augmenter la contrainte sur les chaînes
pointées. Ici, je pense que C et C++ divergent, donc tout ce que j'écris
peut ne pas être vrai en C++.
En C, donc, la règle sur const signifiant "ne sera pas modifié" s'applique
uniquement au paramètre lui-même, pas aux composants à partir desquels est
construit son type.
Détail: 6.3.2.2/6.5.2.2 Function calls, par. 2, en partie:
Each argument shall have a type such that its value may be assigned to
an object with the unqualified version of the type of its corresponding
parameter.
Ce qui renvoie vers les affectations: 6.3.16.1/6.5.16.1 Simple assignment,
par.1, en partie:
- both operands are pointers to qualified or unqualified versions of
compatible types, and the type pointed to by the left has all the
qualifiers of the type pointed to by the right;
Il faut donc s'en remettre aux règles de compatibilité de types pour voir si
on peut ajouter des qualificateurs sur les sous-éléments. Et là, surprise,
si tu changes les qualificateurs, ce n'est plus compatible: 6.5.4.1/6.7.5.1
Pointer declarators, par.2:
For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types.
Ce qui explique les râleries de GCC C.
En c65d17$7hd$, Marc Boyer va escriure:Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char*
argv[].
La déclaration "correcte" est
char * const argv[]
<DIGRESSION>
Pour des raisons de compatibilité avec l'existant, l'officielle n'a pas le
const. Mais la norme C dans son texte refuse l'autorisation de modifier les
éléments du tableau: 5.1.2.2.1p2, en partie:
-- The parameters *argc* and *argv* and the strings pointed to by the
*argv* array shall be modifiable by the program, and retain their last-
stored values between program startup and program termination.
Par élimination, tout est modifiable, sauf les éléments du tableau argv
original. Autrement sit, si tu veux modifier les éléments de argv[], il faut
d'arbord copier le tableau ailleurs, faire les modifications que tu veux, et
ensuite réaffecter argv vers ta copie locale.
</DIGRESSION>
[SNIP]
Mais à partir du moment où il y a un const dans le type,
GCC C devient féroce, et refuse de convertir un tableau non modifiable
(argv) en tableau modifiable (ton paramètre), même si dans le même temps tu
augmentes la contrainte sur les éléments pointés (modifiables selon la
norme, non modifiés selon ton prototype).
D'autre part, il y a la tentative d'augmenter la contrainte sur les chaînes
pointées. Ici, je pense que C et C++ divergent, donc tout ce que j'écris
peut ne pas être vrai en C++.
En C, donc, la règle sur const signifiant "ne sera pas modifié" s'applique
uniquement au paramètre lui-même, pas aux composants à partir desquels est
construit son type.
Détail: 6.3.2.2/6.5.2.2 Function calls, par. 2, en partie:
Each argument shall have a type such that its value may be assigned to
an object with the unqualified version of the type of its corresponding
parameter.
Ce qui renvoie vers les affectations: 6.3.16.1/6.5.16.1 Simple assignment,
par.1, en partie:
- both operands are pointers to qualified or unqualified versions of
compatible types, and the type pointed to by the left has all the
qualifiers of the type pointed to by the right;
Il faut donc s'en remettre aux règles de compatibilité de types pour voir si
on peut ajouter des qualificateurs sur les sous-éléments. Et là, surprise,
si tu changes les qualificateurs, ce n'est plus compatible: 6.5.4.1/6.7.5.1
Pointer declarators, par.2:
For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types.
Ce qui explique les râleries de GCC C.
Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char* argv[].
Je comprends qu'avec un pointeur de pointeur de char, on peut modifier
l'argument, dans le sens ou on fait pointeur sur "autre chose", mais bon,
si je veux interdire une modif de l'argument, j'ecris
char const * const argv[]
donc deja, je comprends pas trop...
Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char* argv[].
Je comprends qu'avec un pointeur de pointeur de char, on peut modifier
l'argument, dans le sens ou on fait pointeur sur "autre chose", mais bon,
si je veux interdire une modif de l'argument, j'ecris
char const * const argv[]
donc deja, je comprends pas trop...
Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char* argv[].
Je comprends qu'avec un pointeur de pointeur de char, on peut modifier
l'argument, dans le sens ou on fait pointeur sur "autre chose", mais bon,
si je veux interdire une modif de l'argument, j'ecris
char const * const argv[]
donc deja, je comprends pas trop...
In article <c65j3e$td8$, Antoine Leca wrote:En c65d17$7hd$, Marc Boyer va escriure:Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char*
argv[].
La déclaration "correcte" est
char * const argv[]
Autrement [d]it, si tu veux modifier les éléments de
argv[], il faut d'arbord copier le tableau ailleurs, faire les
modifications que tu veux, et ensuite réaffecter argv vers ta copie
locale.
En fait, dans l'usage immediat que j'en vois, ca permet de modifier
l'ordre des parametres, pour, par exemple, mettre les options au
debut de la ligne de commande et se faciliter l'analyse).
</DIGRESSION>
<couic>
En C, donc, la règle sur const signifiant "ne sera pas modifié"
s'applique uniquement au paramètre lui-même, pas aux composants à
partir desquels est construit son type.
La, je seche... Prenons
void foo(const char* s)
qu'est-ce que le parametre ( s ?)
et son type c'est char* ou const char* ?
Détail: 6.3.2.2/6.5.2.2 Function calls, par. 2, en partie:
Each argument shall have a type such that its value may be
assigned to an object with the unqualified version of the type
of its corresponding parameter.
unqualified == pas de const ?
si le type c'est char const * const, le unqualified, c'est
char const * ou char* ?
Ce qui renvoie vers les affectations: 6.3.16.1/6.5.16.1 Simple
assignment, par.1, en partie:
- both operands are pointers to qualified or unqualified
versions of compatible types, and the type pointed to by the
left has all the qualifiers of the type pointed to by the right;
Il faut donc s'en remettre aux règles de compatibilité de types pour
voir si on peut ajouter des qualificateurs sur les sous-éléments. Et
là, surprise, si tu changes les qualificateurs, ce n'est plus
compatible: 6.5.4.1/6.7.5.1 Pointer declarators, par.2:
For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types.
Ce qui explique les râleries de GCC C.
Heuh... J'ai pas tout saisi la...
In article <c65j3e$td8$1@shakotay.alphanet.ch>, Antoine Leca wrote:
En c65d17$7hd$1@news.cict.fr, Marc Boyer va escriure:
Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char*
argv[].
La déclaration "correcte" est
char * const argv[]
Autrement [d]it, si tu veux modifier les éléments de
argv[], il faut d'arbord copier le tableau ailleurs, faire les
modifications que tu veux, et ensuite réaffecter argv vers ta copie
locale.
En fait, dans l'usage immediat que j'en vois, ca permet de modifier
l'ordre des parametres, pour, par exemple, mettre les options au
debut de la ligne de commande et se faciliter l'analyse).
</DIGRESSION>
<couic>
En C, donc, la règle sur const signifiant "ne sera pas modifié"
s'applique uniquement au paramètre lui-même, pas aux composants à
partir desquels est construit son type.
La, je seche... Prenons
void foo(const char* s)
qu'est-ce que le parametre ( s ?)
et son type c'est char* ou const char* ?
Détail: 6.3.2.2/6.5.2.2 Function calls, par. 2, en partie:
Each argument shall have a type such that its value may be
assigned to an object with the unqualified version of the type
of its corresponding parameter.
unqualified == pas de const ?
si le type c'est char const * const, le unqualified, c'est
char const * ou char* ?
Ce qui renvoie vers les affectations: 6.3.16.1/6.5.16.1 Simple
assignment, par.1, en partie:
- both operands are pointers to qualified or unqualified
versions of compatible types, and the type pointed to by the
left has all the qualifiers of the type pointed to by the right;
Il faut donc s'en remettre aux règles de compatibilité de types pour
voir si on peut ajouter des qualificateurs sur les sous-éléments. Et
là, surprise, si tu changes les qualificateurs, ce n'est plus
compatible: 6.5.4.1/6.7.5.1 Pointer declarators, par.2:
For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types.
Ce qui explique les râleries de GCC C.
Heuh... J'ai pas tout saisi la...
In article <c65j3e$td8$, Antoine Leca wrote:En c65d17$7hd$, Marc Boyer va escriure:Ni gcc ni g++ n'acceptent la conversion char* argv[] en const char*
argv[].
La déclaration "correcte" est
char * const argv[]
Autrement [d]it, si tu veux modifier les éléments de
argv[], il faut d'arbord copier le tableau ailleurs, faire les
modifications que tu veux, et ensuite réaffecter argv vers ta copie
locale.
En fait, dans l'usage immediat que j'en vois, ca permet de modifier
l'ordre des parametres, pour, par exemple, mettre les options au
debut de la ligne de commande et se faciliter l'analyse).
</DIGRESSION>
<couic>
En C, donc, la règle sur const signifiant "ne sera pas modifié"
s'applique uniquement au paramètre lui-même, pas aux composants à
partir desquels est construit son type.
La, je seche... Prenons
void foo(const char* s)
qu'est-ce que le parametre ( s ?)
et son type c'est char* ou const char* ?
Détail: 6.3.2.2/6.5.2.2 Function calls, par. 2, en partie:
Each argument shall have a type such that its value may be
assigned to an object with the unqualified version of the type
of its corresponding parameter.
unqualified == pas de const ?
si le type c'est char const * const, le unqualified, c'est
char const * ou char* ?
Ce qui renvoie vers les affectations: 6.3.16.1/6.5.16.1 Simple
assignment, par.1, en partie:
- both operands are pointers to qualified or unqualified
versions of compatible types, and the type pointed to by the
left has all the qualifiers of the type pointed to by the right;
Il faut donc s'en remettre aux règles de compatibilité de types pour
voir si on peut ajouter des qualificateurs sur les sous-éléments. Et
là, surprise, si tu changes les qualificateurs, ce n'est plus
compatible: 6.5.4.1/6.7.5.1 Pointer declarators, par.2:
For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types.
Ce qui explique les râleries de GCC C.
Heuh... J'ai pas tout saisi la...
On 21 Apr 2004 08:57:11 GMT, Marc Boyer
wrote:
Il n'y pas de conversion automatique char** vers const char** parce
que la norme le dit ;-) On en a déjà parlé ici plusieurs fois.
Un exemple qui montre qu'une conversion automatique ne serait pas sure
const char *cc = "hello world!";
void foo(const char **pp)
{
*pp = cc;
}
char *p;
foo(&p); /* si c'était légal on pourrait */
p[0]="H"; /* dévier un char* sur une chaîne constante. */
...oops.....
On 21 Apr 2004 08:57:11 GMT, Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote:
Il n'y pas de conversion automatique char** vers const char** parce
que la norme le dit ;-) On en a déjà parlé ici plusieurs fois.
Un exemple qui montre qu'une conversion automatique ne serait pas sure
const char *cc = "hello world!";
void foo(const char **pp)
{
*pp = cc;
}
char *p;
foo(&p); /* si c'était légal on pourrait */
p[0]="H"; /* dévier un char* sur une chaîne constante. */
...oops.....
On 21 Apr 2004 08:57:11 GMT, Marc Boyer
wrote:
Il n'y pas de conversion automatique char** vers const char** parce
que la norme le dit ;-) On en a déjà parlé ici plusieurs fois.
Un exemple qui montre qu'une conversion automatique ne serait pas sure
const char *cc = "hello world!";
void foo(const char **pp)
{
*pp = cc;
}
char *p;
foo(&p); /* si c'était légal on pourrait */
p[0]="H"; /* dévier un char* sur une chaîne constante. */
...oops.....
Ceci etant dit, la conversion char** vers char const * const *
elle serait sure dans ce cas (enfin, il me semble).
D'ailleurs, g++ semble l'accepter.
J'ai rate un autre truc ?
Ceci etant dit, la conversion char** vers char const * const *
elle serait sure dans ce cas (enfin, il me semble).
D'ailleurs, g++ semble l'accepter.
J'ai rate un autre truc ?
Ceci etant dit, la conversion char** vers char const * const *
elle serait sure dans ce cas (enfin, il me semble).
D'ailleurs, g++ semble l'accepter.
J'ai rate un autre truc ?
Les regles C++ telles que je m'en souviens sont:
- si a un niveau, la source a un const, alors la destination doit
l'avoir aussi; de meme pour volatile
- si a un niveau, la destination a un const et la source pas, alors
la destination doit avoir un const a tous les niveaux precedants
Exemple de ce que la deuxieme regle veut eviter:
int main() {
char const c = 'c';
char* pc;
char const** pcc = &pc; // interdit
*pcc = &c;
*pc = 'C'; // modifie c
}
Les regles C++ telles que je m'en souviens sont:
- si a un niveau, la source a un const, alors la destination doit
l'avoir aussi; de meme pour volatile
- si a un niveau, la destination a un const et la source pas, alors
la destination doit avoir un const a tous les niveaux precedants
Exemple de ce que la deuxieme regle veut eviter:
int main() {
char const c = 'c';
char* pc;
char const** pcc = &pc; // interdit
*pcc = &c;
*pc = 'C'; // modifie c
}
Les regles C++ telles que je m'en souviens sont:
- si a un niveau, la source a un const, alors la destination doit
l'avoir aussi; de meme pour volatile
- si a un niveau, la destination a un const et la source pas, alors
la destination doit avoir un const a tous les niveaux precedants
Exemple de ce que la deuxieme regle veut eviter:
int main() {
char const c = 'c';
char* pc;
char const** pcc = &pc; // interdit
*pcc = &c;
*pc = 'C'; // modifie c
}
En fait, au début j'ai répondu pensant à un problème lié à argv, où GCC
serait intelligent. Et ensuite je me suis aperçu que le problème était plus
de fond, en rien spécifique à argv. J'ai laissé la digression, que je
trouvais intéressante (chacun ses goûts ;-)), mais cela a dû t'égarer plus
qu'autre chose. Désolé.
Attention, il y a trois niveaux (ou plus).
Le premier const (à partir de la gauche, donc à droite du *), saute
automatiquement, puisqu'il faut bien passer l'argument (il s'applique dans
la définition de la fonction). C'est le 6.3.2.2/6.5.2.2 ci-dessous.
Le deuxième const saute en vertu d'une règle spéciale, destinée si je me
rappelle bien à faciliter la compatibilité et l'utilisabilité de const, en
particulier la croyance que « const * pour un paramètre signifie que la
fonction ne modifie pas l'argument », une utile manière de voir les choses
mais la norme n'est pas formulée de cette manière.
Détail: 6.3.2.2/6.5.2.2 Function calls, par. 2, en partie:
Each argument shall have a type such that its value may be
assigned to an object with the unqualified version of the type
of its corresponding parameter.
unqualified == pas de const ?
Oui, mais uniquement pour le type du paramètre, _pas_ pour le type vers
lequel ce type pointe.si le type c'est char const * const, le unqualified, c'est
char const * ou char* ?
char const *
Ça va mieux, maintenant ?
En fait, au début j'ai répondu pensant à un problème lié à argv, où GCC
serait intelligent. Et ensuite je me suis aperçu que le problème était plus
de fond, en rien spécifique à argv. J'ai laissé la digression, que je
trouvais intéressante (chacun ses goûts ;-)), mais cela a dû t'égarer plus
qu'autre chose. Désolé.
Attention, il y a trois niveaux (ou plus).
Le premier const (à partir de la gauche, donc à droite du *), saute
automatiquement, puisqu'il faut bien passer l'argument (il s'applique dans
la définition de la fonction). C'est le 6.3.2.2/6.5.2.2 ci-dessous.
Le deuxième const saute en vertu d'une règle spéciale, destinée si je me
rappelle bien à faciliter la compatibilité et l'utilisabilité de const, en
particulier la croyance que « const * pour un paramètre signifie que la
fonction ne modifie pas l'argument », une utile manière de voir les choses
mais la norme n'est pas formulée de cette manière.
Détail: 6.3.2.2/6.5.2.2 Function calls, par. 2, en partie:
Each argument shall have a type such that its value may be
assigned to an object with the unqualified version of the type
of its corresponding parameter.
unqualified == pas de const ?
Oui, mais uniquement pour le type du paramètre, _pas_ pour le type vers
lequel ce type pointe.
si le type c'est char const * const, le unqualified, c'est
char const * ou char* ?
char const *
Ça va mieux, maintenant ?
En fait, au début j'ai répondu pensant à un problème lié à argv, où GCC
serait intelligent. Et ensuite je me suis aperçu que le problème était plus
de fond, en rien spécifique à argv. J'ai laissé la digression, que je
trouvais intéressante (chacun ses goûts ;-)), mais cela a dû t'égarer plus
qu'autre chose. Désolé.
Attention, il y a trois niveaux (ou plus).
Le premier const (à partir de la gauche, donc à droite du *), saute
automatiquement, puisqu'il faut bien passer l'argument (il s'applique dans
la définition de la fonction). C'est le 6.3.2.2/6.5.2.2 ci-dessous.
Le deuxième const saute en vertu d'une règle spéciale, destinée si je me
rappelle bien à faciliter la compatibilité et l'utilisabilité de const, en
particulier la croyance que « const * pour un paramètre signifie que la
fonction ne modifie pas l'argument », une utile manière de voir les choses
mais la norme n'est pas formulée de cette manière.
Détail: 6.3.2.2/6.5.2.2 Function calls, par. 2, en partie:
Each argument shall have a type such that its value may be
assigned to an object with the unqualified version of the type
of its corresponding parameter.
unqualified == pas de const ?
Oui, mais uniquement pour le type du paramètre, _pas_ pour le type vers
lequel ce type pointe.si le type c'est char const * const, le unqualified, c'est
char const * ou char* ?
char const *
Ça va mieux, maintenant ?
Antoine Leca wrote:Le deuxième const saute en vertu d'une règle spéciale, destinée si
je me rappelle bien à faciliter la compatibilité et l'utilisabilité
de const, en particulier la croyance que « const * pour un paramètre
signifie que la fonction ne modifie pas l'argument », une utile
manière de voir les choses mais la norme n'est pas formulée de cette
manière.
J'avoue avoir présenté le const à mes élèves justement
avec cette idée de non-modification.
Je me demande que leur dire maintenant que le cours
s'attarde sur les pointeurs...
Oui, mais j'hésite sur la manière de présenter la chose...
Le coup de "le deuxième const saute pour faire comme
si le const signifiait 'ne modifie pas son paramètre'", je
le sens mal...
En gros, la règle c'est:
- le premier const saute (c'est de toute façon une copie)
- le second, on accepte la conversion non const->const,
pour dire qu'une fonction ne modifie pas son paramètre
- pour les autres, il faut égalité parce que c'est comme
ça
(je peux montrer le contre exemple qui m'a été fournit
sans m'attarder sur le fait qu'en rajoutant un cast de
plus, ce serait sans danger mais refusé quand même)...
Antoine Leca wrote:
Le deuxième const saute en vertu d'une règle spéciale, destinée si
je me rappelle bien à faciliter la compatibilité et l'utilisabilité
de const, en particulier la croyance que « const * pour un paramètre
signifie que la fonction ne modifie pas l'argument », une utile
manière de voir les choses mais la norme n'est pas formulée de cette
manière.
J'avoue avoir présenté le const à mes élèves justement
avec cette idée de non-modification.
Je me demande que leur dire maintenant que le cours
s'attarde sur les pointeurs...
Oui, mais j'hésite sur la manière de présenter la chose...
Le coup de "le deuxième const saute pour faire comme
si le const signifiait 'ne modifie pas son paramètre'", je
le sens mal...
En gros, la règle c'est:
- le premier const saute (c'est de toute façon une copie)
- le second, on accepte la conversion non const->const,
pour dire qu'une fonction ne modifie pas son paramètre
- pour les autres, il faut égalité parce que c'est comme
ça
(je peux montrer le contre exemple qui m'a été fournit
sans m'attarder sur le fait qu'en rajoutant un cast de
plus, ce serait sans danger mais refusé quand même)...
Antoine Leca wrote:Le deuxième const saute en vertu d'une règle spéciale, destinée si
je me rappelle bien à faciliter la compatibilité et l'utilisabilité
de const, en particulier la croyance que « const * pour un paramètre
signifie que la fonction ne modifie pas l'argument », une utile
manière de voir les choses mais la norme n'est pas formulée de cette
manière.
J'avoue avoir présenté le const à mes élèves justement
avec cette idée de non-modification.
Je me demande que leur dire maintenant que le cours
s'attarde sur les pointeurs...
Oui, mais j'hésite sur la manière de présenter la chose...
Le coup de "le deuxième const saute pour faire comme
si le const signifiait 'ne modifie pas son paramètre'", je
le sens mal...
En gros, la règle c'est:
- le premier const saute (c'est de toute façon une copie)
- le second, on accepte la conversion non const->const,
pour dire qu'une fonction ne modifie pas son paramètre
- pour les autres, il faut égalité parce que c'est comme
ça
(je peux montrer le contre exemple qui m'a été fournit
sans m'attarder sur le fait qu'en rajoutant un cast de
plus, ce serait sans danger mais refusé quand même)...