Bonjour,
Soit le programme suivant :
/*
* ---------------- adresseTableau.c -------------------
*/
#include <stdio.h>
int main(void)
{
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
return 0;
}
je pense que (void *) a est un raccourci pour &a[0]. et c'est un fait
Bonjour,
Soit le programme suivant :
/*
* ---------------- adresseTableau.c -------------------
*/
#include <stdio.h>
int main(void)
{
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
return 0;
}
je pense que (void *) a est un raccourci pour &a[0]. et c'est un fait
Bonjour,
Soit le programme suivant :
/*
* ---------------- adresseTableau.c -------------------
*/
#include <stdio.h>
int main(void)
{
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
return 0;
}
je pense que (void *) a est un raccourci pour &a[0]. et c'est un fait
et c'est un fait
que l'adresse d'un tableau est la même que l'adresse de son premier
element, du moins en C.
et c'est un fait
que l'adresse d'un tableau est la même que l'adresse de son premier
element, du moins en C.
et c'est un fait
que l'adresse d'un tableau est la même que l'adresse de son premier
element, du moins en C.
Bonjour,
Soit le programme suivant :
/*
* ---------------- adresseTableau.c -------------------
*/
#include <stdio.h>
int main(void)
{
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
return 0;
}
/*
* -----------------------------------------------------------
*/
Il m'affiche deux valeurs identiques. Cette coïncidence dépend-elle
exclusivement de l'implémentation ?
J'ai regardé la norme et je ne vois rien qui permette de l'affirmer (à
la différence de l'adresse d'une structure, cf. 6.7.2.1#13). Pourtant,
en consultant les archives de fclc, certains intervenants laissent
penser que oui. Pour clc, le discours est plus prudent mais aucune
réponse catégorique, comme si la question était mal posée.
Bonjour,
Soit le programme suivant :
/*
* ---------------- adresseTableau.c -------------------
*/
#include <stdio.h>
int main(void)
{
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
return 0;
}
/*
* -----------------------------------------------------------
*/
Il m'affiche deux valeurs identiques. Cette coïncidence dépend-elle
exclusivement de l'implémentation ?
J'ai regardé la norme et je ne vois rien qui permette de l'affirmer (à
la différence de l'adresse d'une structure, cf. 6.7.2.1#13). Pourtant,
en consultant les archives de fclc, certains intervenants laissent
penser que oui. Pour clc, le discours est plus prudent mais aucune
réponse catégorique, comme si la question était mal posée.
Bonjour,
Soit le programme suivant :
/*
* ---------------- adresseTableau.c -------------------
*/
#include <stdio.h>
int main(void)
{
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
return 0;
}
/*
* -----------------------------------------------------------
*/
Il m'affiche deux valeurs identiques. Cette coïncidence dépend-elle
exclusivement de l'implémentation ?
J'ai regardé la norme et je ne vois rien qui permette de l'affirmer (à
la différence de l'adresse d'une structure, cf. 6.7.2.1#13). Pourtant,
en consultant les archives de fclc, certains intervenants laissent
penser que oui. Pour clc, le discours est plus prudent mais aucune
réponse catégorique, comme si la question était mal posée.
Bonjour,
Soit le programme suivant :
/*
* ---------------- adresseTableau.c -------------------
*/
#include <stdio.h>
int main(void)
{
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
return 0;
}
/*
* -----------------------------------------------------------
*/
Il m'affiche deux valeurs identiques. Cette coïncidence dépend-elle
exclusivement de l'implémentation ?
J'ai regardé la norme et je ne vois rien qui permette de l'affirmer (à
la différence de l'adresse d'une structure, cf. 6.7.2.1#13). Pourtant,
en consultant les archives de fclc, certains intervenants laissent
penser que oui. Pour clc, le discours est plus prudent mais aucune
réponse catégorique, comme si la question était mal posée.
La réponse la moins vague que j'aie pu trouver est celle de DMR sur
comp.std.c en 1999 qui dit :
/In the usual implementation the bit value of &a[0] and &a will be the
same,/
Bonjour,
Soit le programme suivant :
/*
* ---------------- adresseTableau.c -------------------
*/
#include <stdio.h>
int main(void)
{
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
return 0;
}
/*
* -----------------------------------------------------------
*/
Il m'affiche deux valeurs identiques. Cette coïncidence dépend-elle
exclusivement de l'implémentation ?
J'ai regardé la norme et je ne vois rien qui permette de l'affirmer (à
la différence de l'adresse d'une structure, cf. 6.7.2.1#13). Pourtant,
en consultant les archives de fclc, certains intervenants laissent
penser que oui. Pour clc, le discours est plus prudent mais aucune
réponse catégorique, comme si la question était mal posée.
La réponse la moins vague que j'aie pu trouver est celle de DMR sur
comp.std.c en 1999 qui dit :
/In the usual implementation the bit value of &a[0] and &a will be the
same,/
Bonjour,
Soit le programme suivant :
/*
* ---------------- adresseTableau.c -------------------
*/
#include <stdio.h>
int main(void)
{
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
return 0;
}
/*
* -----------------------------------------------------------
*/
Il m'affiche deux valeurs identiques. Cette coïncidence dépend-elle
exclusivement de l'implémentation ?
J'ai regardé la norme et je ne vois rien qui permette de l'affirmer (à
la différence de l'adresse d'une structure, cf. 6.7.2.1#13). Pourtant,
en consultant les archives de fclc, certains intervenants laissent
penser que oui. Pour clc, le discours est plus prudent mais aucune
réponse catégorique, comme si la question était mal posée.
La réponse la moins vague que j'aie pu trouver est celle de DMR sur
comp.std.c en 1999 qui dit :
/In the usual implementation the bit value of &a[0] and &a will be the
same,/
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
Il m'affiche deux valeurs identiques. Cette coïncidence dépend-elle
exclusivement de l'implémentation ?
La réponse la moins vague que j'aie pu trouver est celle de DMR sur
comp.std.c en 1999 qui dit :
/In the usual implementation the bit value of &a[0] and &a will be the
same,/
Comment faut-il interpréter ce /In the usual implementation/ ?
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
Il m'affiche deux valeurs identiques. Cette coïncidence dépend-elle
exclusivement de l'implémentation ?
La réponse la moins vague que j'aie pu trouver est celle de DMR sur
comp.std.c en 1999 qui dit :
/In the usual implementation the bit value of &a[0] and &a will be the
same,/
Comment faut-il interpréter ce /In the usual implementation/ ?
int a[2] = { 100, 200 };
printf("%pn%pn", (void *) a, (void *) &a);
Il m'affiche deux valeurs identiques. Cette coïncidence dépend-elle
exclusivement de l'implémentation ?
La réponse la moins vague que j'aie pu trouver est celle de DMR sur
comp.std.c en 1999 qui dit :
/In the usual implementation the bit value of &a[0] and &a will be the
same,/
Comment faut-il interpréter ce /In the usual implementation/ ?
On pourrait peut-être imaginer un compilateur hypothétique qui
stoque 'quelque chose' au début d'un tableau, avant le premier
élément (si j'ai pas raté un truc).
Dans la pratique, ce compilo casserait surement du code de
ci de là....
On pourrait peut-être imaginer un compilateur hypothétique qui
stoque 'quelque chose' au début d'un tableau, avant le premier
élément (si j'ai pas raté un truc).
Dans la pratique, ce compilo casserait surement du code de
ci de là....
On pourrait peut-être imaginer un compilateur hypothétique qui
stoque 'quelque chose' au début d'un tableau, avant le premier
élément (si j'ai pas raté un truc).
Dans la pratique, ce compilo casserait surement du code de
ci de là....
Oui, mais le code en question est probablement mal écrit. Les raisons
d'utiliser &a sont normalement très rares, en général liées à l'utilisation
de tableaux « multi-dimensionnels », et le code résultant est très souvent
incorrect du point de vue de la norme (suppose un adressage linéaire)... Et
quand le code est correct, je ne pense pas que les valeurs soient jamais
comparées à d'autres types, donc les soucis ne devraient pas apparaître !
Oui, mais le code en question est probablement mal écrit. Les raisons
d'utiliser &a sont normalement très rares, en général liées à l'utilisation
de tableaux « multi-dimensionnels », et le code résultant est très souvent
incorrect du point de vue de la norme (suppose un adressage linéaire)... Et
quand le code est correct, je ne pense pas que les valeurs soient jamais
comparées à d'autres types, donc les soucis ne devraient pas apparaître !
Oui, mais le code en question est probablement mal écrit. Les raisons
d'utiliser &a sont normalement très rares, en général liées à l'utilisation
de tableaux « multi-dimensionnels », et le code résultant est très souvent
incorrect du point de vue de la norme (suppose un adressage linéaire)... Et
quand le code est correct, je ne pense pas que les valeurs soient jamais
comparées à d'autres types, donc les soucis ne devraient pas apparaître !
Pour le cas des opérateurs d'égalité, il est aussi possible de comparer un
pointeur arbitraire (au hasard, &a !) avec un pointeur universel void*; dans
ton exemple cela imposerait un transtypage avec conversion de int* vers
void*, mais si on prend le cas peu différent de char b[2], on peut faire
abstraction de cette conversion supplémentaire. On en réduit le champ à
6.5.9p6, qui est le plus précis (que j'ai trouvé) que la norme puisse
t'offrir :
Two pointers compare equal if and only if [...] both are pointers to
the
same object (including a pointer to an object and a subobject at its
beginning) [...]
En clair, avec
char b[2] = { 100, 200 };
void* p = b; /* sans effet de conversion, d'après 6.2.5p27 */
on a
p == &b
Rappel : les valeurs binaires peuvent être très différentes !
Pour le cas des opérateurs d'égalité, il est aussi possible de comparer un
pointeur arbitraire (au hasard, &a !) avec un pointeur universel void*; dans
ton exemple cela imposerait un transtypage avec conversion de int* vers
void*, mais si on prend le cas peu différent de char b[2], on peut faire
abstraction de cette conversion supplémentaire. On en réduit le champ à
6.5.9p6, qui est le plus précis (que j'ai trouvé) que la norme puisse
t'offrir :
Two pointers compare equal if and only if [...] both are pointers to
the
same object (including a pointer to an object and a subobject at its
beginning) [...]
En clair, avec
char b[2] = { 100, 200 };
void* p = b; /* sans effet de conversion, d'après 6.2.5p27 */
on a
p == &b
Rappel : les valeurs binaires peuvent être très différentes !
Pour le cas des opérateurs d'égalité, il est aussi possible de comparer un
pointeur arbitraire (au hasard, &a !) avec un pointeur universel void*; dans
ton exemple cela imposerait un transtypage avec conversion de int* vers
void*, mais si on prend le cas peu différent de char b[2], on peut faire
abstraction de cette conversion supplémentaire. On en réduit le champ à
6.5.9p6, qui est le plus précis (que j'ai trouvé) que la norme puisse
t'offrir :
Two pointers compare equal if and only if [...] both are pointers to
the
same object (including a pointer to an object and a subobject at its
beginning) [...]
En clair, avec
char b[2] = { 100, 200 };
void* p = b; /* sans effet de conversion, d'après 6.2.5p27 */
on a
p == &b
Rappel : les valeurs binaires peuvent être très différentes !
On 2008-02-12, Antoine Leca wrote:En clair, avec
char b[2] = { 100, 200 };
void* p = b; /* sans effet de conversion, d'après 6.2.5p27 */
Pardon, est-ce que tes doigts n'ont pas fourché sur le clavier.
Parce que dans ce que j'ai sous les yeux, 6.2.5p27, c'est un exemple
sur float* et const float *.
On 2008-02-12, Antoine Leca <root@localhost.invalid> wrote:
En clair, avec
char b[2] = { 100, 200 };
void* p = b; /* sans effet de conversion, d'après 6.2.5p27 */
Pardon, est-ce que tes doigts n'ont pas fourché sur le clavier.
Parce que dans ce que j'ai sous les yeux, 6.2.5p27, c'est un exemple
sur float* et const float *.
On 2008-02-12, Antoine Leca wrote:En clair, avec
char b[2] = { 100, 200 };
void* p = b; /* sans effet de conversion, d'après 6.2.5p27 */
Pardon, est-ce que tes doigts n'ont pas fourché sur le clavier.
Parce que dans ce que j'ai sous les yeux, 6.2.5p27, c'est un exemple
sur float* et const float *.
En news:, Marc Boyer va escriure:On pourrait peut-être imaginer un compilateur hypothétique qui
stoque 'quelque chose' au début d'un tableau, avant le premier
élément (si j'ai pas raté un truc).
Rigolo comme idée.
J'ai examiné plusieurs facettes (y compris la construction des structures,
6.7.2.1p13 en particulier, 6.2.5p20 ou 6.5.6p8), et je n'ai pas trouvé non
plus de motifs pour rejeter cela /a priori/. Il faudrait seulement des
versions spéciales pour == (6.5.9) ou sizeof (6.5.3.4) qui ferait
abstraction du « quelque chose ».
On peut aussi imaginer une implémentation où les tableaux seraient en fait
des descripteurs de tableaux, en gros une structure stockée «ailleurs», avec
entre autres un pointeur vers les véritables données. Dans ces conditions,
&a retournerait l'adresse de ce descripteur, qui serait incommensurable
(sauf conversion) avec les données elles-mêmes. Il est possible de glisser
de tels descripteurs /derrière/ le tableau dans une structure, par exemple
(6.7.2.1p15). Un des intérêts de ce genre d'implémentation serait de pouvoir
implémenter une vérification dynamique des bornes des tableaux.
Je n'ai pas vérifié en profondeur, mais je pense que cela doit être conforme
(moyennant une pelleté de restrictions d'implémentations à documenter.)
Dans la pratique, ce compilo casserait surement du code de
ci de là....
Oui, mais le code en question est probablement mal écrit. Les raisons
d'utiliser &a sont normalement très rares, en général liées à l'utilisation
de tableaux « multi-dimensionnels », et le code résultant est très souvent
incorrect du point de vue de la norme (suppose un adressage linéaire)... Et
quand le code est correct, je ne pense pas que les valeurs soient jamais
comparées à d'autres types, donc les soucis ne devraient pas apparaître !
En news:slrnfr0o13.r2n.Marc.Boyer@ubu.enseeiht.fr, Marc Boyer va escriure:
On pourrait peut-être imaginer un compilateur hypothétique qui
stoque 'quelque chose' au début d'un tableau, avant le premier
élément (si j'ai pas raté un truc).
Rigolo comme idée.
J'ai examiné plusieurs facettes (y compris la construction des structures,
6.7.2.1p13 en particulier, 6.2.5p20 ou 6.5.6p8), et je n'ai pas trouvé non
plus de motifs pour rejeter cela /a priori/. Il faudrait seulement des
versions spéciales pour == (6.5.9) ou sizeof (6.5.3.4) qui ferait
abstraction du « quelque chose ».
On peut aussi imaginer une implémentation où les tableaux seraient en fait
des descripteurs de tableaux, en gros une structure stockée «ailleurs», avec
entre autres un pointeur vers les véritables données. Dans ces conditions,
&a retournerait l'adresse de ce descripteur, qui serait incommensurable
(sauf conversion) avec les données elles-mêmes. Il est possible de glisser
de tels descripteurs /derrière/ le tableau dans une structure, par exemple
(6.7.2.1p15). Un des intérêts de ce genre d'implémentation serait de pouvoir
implémenter une vérification dynamique des bornes des tableaux.
Je n'ai pas vérifié en profondeur, mais je pense que cela doit être conforme
(moyennant une pelleté de restrictions d'implémentations à documenter.)
Dans la pratique, ce compilo casserait surement du code de
ci de là....
Oui, mais le code en question est probablement mal écrit. Les raisons
d'utiliser &a sont normalement très rares, en général liées à l'utilisation
de tableaux « multi-dimensionnels », et le code résultant est très souvent
incorrect du point de vue de la norme (suppose un adressage linéaire)... Et
quand le code est correct, je ne pense pas que les valeurs soient jamais
comparées à d'autres types, donc les soucis ne devraient pas apparaître !
En news:, Marc Boyer va escriure:On pourrait peut-être imaginer un compilateur hypothétique qui
stoque 'quelque chose' au début d'un tableau, avant le premier
élément (si j'ai pas raté un truc).
Rigolo comme idée.
J'ai examiné plusieurs facettes (y compris la construction des structures,
6.7.2.1p13 en particulier, 6.2.5p20 ou 6.5.6p8), et je n'ai pas trouvé non
plus de motifs pour rejeter cela /a priori/. Il faudrait seulement des
versions spéciales pour == (6.5.9) ou sizeof (6.5.3.4) qui ferait
abstraction du « quelque chose ».
On peut aussi imaginer une implémentation où les tableaux seraient en fait
des descripteurs de tableaux, en gros une structure stockée «ailleurs», avec
entre autres un pointeur vers les véritables données. Dans ces conditions,
&a retournerait l'adresse de ce descripteur, qui serait incommensurable
(sauf conversion) avec les données elles-mêmes. Il est possible de glisser
de tels descripteurs /derrière/ le tableau dans une structure, par exemple
(6.7.2.1p15). Un des intérêts de ce genre d'implémentation serait de pouvoir
implémenter une vérification dynamique des bornes des tableaux.
Je n'ai pas vérifié en profondeur, mais je pense que cela doit être conforme
(moyennant une pelleté de restrictions d'implémentations à documenter.)
Dans la pratique, ce compilo casserait surement du code de
ci de là....
Oui, mais le code en question est probablement mal écrit. Les raisons
d'utiliser &a sont normalement très rares, en général liées à l'utilisation
de tableaux « multi-dimensionnels », et le code résultant est très souvent
incorrect du point de vue de la norme (suppose un adressage linéaire)... Et
quand le code est correct, je ne pense pas que les valeurs soient jamais
comparées à d'autres types, donc les soucis ne devraient pas apparaître !