[débutant] Pointeurs

Le
Zarak
Bonjour, je m'initie à la notion de pointeurs, et un truc m'obsède
et je n'obtiens pas de réponse.

Quand on créer par exemple un pointeur d'entier : int *x, à ce
moment, &x donne la référence mémoire, ça c'est ok.
*x désigne alors le contenu de cette adresse mémoire, c'est ok =
aussi.
Mais à quoi correspond la valeur de x ?

Lorsque j'affiche &x, j'obtiens 0x22ff74
Lorsque j'affiche x, j'obtiens 0x2

A quoi correspond exactement ce 0x2 ?

Merci beaucoup.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fabien LE LEZ
Le #19970021
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak"
Quand on créer par exemple un pointeur d'entier : int *x, à ce
moment, &x donne la référence mémoire, ça c'est ok.



Attention, &x est un pointeur sur ton pointeur.

Lorsque j'affiche x, j'obtiens 0x2

A quoi correspond exactement ce 0x2 ?



Si tu écris :

int *p;

ta variable "p" est un pointeur non intialisé. C'est-à-dire qu'il peut
pointer vers un espace mémoire qui n'existe pas, ou un espace mémoire
auquel ton programme n'a pas accès.

Écrire "*p", c'est (en gros) prendre la valeur qui se trouve à cet
endroit. Ça n'a pas vraiment de sens.

Typiquement, sur un PC, soit l'OS va râler (et terminer ton
programme), soit tu obtiendras une valeur bidon.


Ceci a un petit peu plus de sens :

int *p= 0;

p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur
à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude :
le programme s'arrête immédiatement.


Enfin, un truc qui peut être utile, et qui ne fait pas planter le
programme :

int n= 42;
int *p= &n;
cout << &n << "n"; // Affiche l'adresse en mémoire de n
cout << p << "n"; // Affiche la même chose
cout << *p << "n"; // Affiche la valeur de n, soit 42.

p est un pointeur sur n, i.e. (grosso modo) l'adresse de n.
=> p == &n

*p est l'entier qui se trouve à l'adresse p, c'est-à-dire n.
=> *p == n
Zarak
Le #19970111
"Fabien LE LEZ"
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak"
Quand on créer par exemple un pointeur d'entier : int *x, à ce
moment, &x donne la référence mémoire, ça c'est ok.



Attention, &x est un pointeur sur ton pointeur



Est-ce que ça signifie en gros "adresse mémoire de l'adresse mémoire" ?

Si oui, dans ce cas je formulerais comme ça :
Après un int* x (oublions le fait que ce soit pas initialisé),
x == adresse mémoire
&x == adresse mémoire de l'adresse mémoire ci-dessus
*x == valeur contenue dans l'adresse mémoire

J'ai bon ou c'est tout faux ? :)
Fabien LE LEZ
Le #19970771
On Sat, 22 Aug 2009 16:10:04 +0200, "Zarak"
Est-ce que ça signifie en gros "adresse mémoire de l'adresse mémoire" ?



En gros, oui.

J'ai bon



Oui.
Zarak
Le #19971421
"Fabien LE LEZ"
On Sat, 22 Aug 2009 16:10:04 +0200, "Zarak"
Est-ce que ça signifie en gros "adresse mémoire de l'adresse mémoire" ?



En gros, oui.

J'ai bon



Oui.



Ok, merci.
pjb
Le #19978701
Fabien LE LEZ
On Sat, 22 Aug 2009 15:34:01 +0200, "Zarak"
Quand on créer par exemple un pointeur d'entier : int *x, à ce
moment, &x donne la référence mémoire, ça c'est ok.



Attention, &x est un pointeur sur ton pointeur.

Lorsque j'affiche x, j'obtiens 0x2

A quoi correspond exactement ce 0x2 ?



Si tu écris :

int *p;

ta variable "p" est un pointeur non intialisé. C'est-à-dire qu'il peut
pointer vers un espace mémoire qui n'existe pas, ou un espace mémoire
auquel ton programme n'a pas accès.

Écrire "*p", c'est (en gros) prendre la valeur qui se trouve à cet
endroit. Ça n'a pas vraiment de sens.

Typiquement, sur un PC, soit l'OS va râler (et terminer ton
programme), soit tu obtiendras une valeur bidon.



Ou pire, ça peut geler la machine. N'importe quoi peut vraiment
arriver. (Malheureusement, le langage n'impose pas aux compilateurs
de marquer les variables non initialisées et de générer une erreur
lorsqu'on les utilise).


Ceci a un petit peu plus de sens :

int *p= 0;

p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur
à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude :
le programme s'arrête immédiatement.



Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une
valeur.

(Malheureusement, le langage n'impose pas aux compilateurs de générer
une erreur lorsqu'on déréférence un pointeur null).



Enfin, un truc qui peut être utile, et qui ne fait pas planter le
programme :

int n= 42;
int *p= &n;
cout << &n << "n"; // Affiche l'adresse en mémoire de n
cout << p << "n"; // Affiche la même chose
cout << *p << "n"; // Affiche la valeur de n, soit 42.

p est un pointeur sur n, i.e. (grosso modo) l'adresse de n.
=> p == &n

*p est l'entier qui se trouve à l'adresse p, c'est-à-dire n.
=> *p == n



On peut se servir de ce truc pour faire des pointeurs qui ne peuvent
jamais être null, donc que l'on puisse toujours déréférencer. Bien
encapsulé dans un template, ça peut être utile...


--
__Pascal Bourguignon__
espie
Le #19980031
In article Pascal J. Bourguignon
Fabien LE LEZ
Ceci a un petit peu plus de sens :

int *p= 0;

p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur
à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude :
le programme s'arrête immédiatement.



Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une
valeur.

(Malheureusement, le langage n'impose pas aux compilateurs de générer
une erreur lorsqu'on déréférence un pointeur null).



Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un
pointeur nul, qui doit etre invalide.

Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.
Marc Boyer
Le #19980301
Le 24-08-2009, Marc Espie
In article Pascal J. Bourguignon
Ceci a un petit peu plus de sens :

int *p= 0;

p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur
à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude :
le programme s'arrête immédiatement.



Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une
valeur.

(Malheureusement, le langage n'impose pas aux compilateurs de générer
une erreur lorsqu'on déréférence un pointeur null).



Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un
pointeur nul, qui doit etre invalide.



De mémoire, déréferencer le pointeur null, c'est juste un "undefined
behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut
être accessible.

Mais si tu as un passage de la norme qui dit que ça *doit* provoquer
une erreur, je m'incline.

D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.

Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.



Je ne pense pas.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Jean-Marc Bourguet
Le #19980421
Marc Boyer
> Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un
> pointeur nul, qui doit etre invalide.

De mémoire, déréferencer le pointeur null, c'est juste un "undefined
behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut
être accessible.

Mais si tu as un passage de la norme qui dit que ça *doit* provoquer
une erreur, je m'incline.

D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.

> Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.

Je ne pense pas.



Un comportement peut etre conforme tout en etant un bug. (Je ne connais
pas MacOS et ne me prononce pas sur le fond de l'histoire).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer
Le #19980491
Le 24-08-2009, Jean-Marc Bourguet
Marc Boyer
> Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un
> pointeur nul, qui doit etre invalide.

De mémoire, déréferencer le pointeur null, c'est juste un "undefined
behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut
être accessible.

Mais si tu as un passage de la norme qui dit que ça *doit* provoquer
une erreur, je m'incline.

D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.

> Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.

Je ne pense pas.



Un comportement peut etre conforme tout en etant un bug. (Je ne connais
pas MacOS et ne me prononce pas sur le fond de l'histoire).



Ca dépend de la définition de bug, en effet.
"It's not a bug, it's a feature"...

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Wykaaa
Le #19980801
Marc Boyer a écrit :
Le 24-08-2009, Marc Espie
In article Pascal J. Bourguignon
Ceci a un petit peu plus de sens :

int *p= 0;

p pointe alors vers "l'adresse 0" ; si tu cherches à obtenir la valeur
à cet endroit (i.e. "cout << *p"), pas de surprise ni d'incertitude :
le programme s'arrête immédiatement.


Pas toujours. Ça dépend du système. Sur MacOS, ça retournerait une
valeur.

(Malheureusement, le langage n'impose pas aux compilateurs de générer
une erreur lorsqu'on déréférence un pointeur null).


Non, pas en C ni en C++. 0 ne correspond pas a l'adresse 0, mais a un
pointeur nul, qui doit etre invalide.



De mémoire, déréferencer le pointeur null, c'est juste un "undefined
behavior", et donc, ça peut être aller taper à l'adresse 0, qui peut
être accessible.



J'ai implémenter un compilateur C sur une machine où l'adresse 0 était
valide (c'était même l'adresse du segment résident du système...).
Evidemment, nous avons remplacé 0 par une valeur invalide sur notre
machine (en l'occurence -1 : FFFFFFFF). Sur une affectation de pointeur
à NULL ou une comparaison, il fallait évidemment remplacer par -1 mais
c'était transparent pour le programmeur (mais quelle cuisine !).

En C++, dans l'annotated reference manual, il est dit, en haut de la
page 36 :
"Note that the null pointer need not be represented by the same bit
pattern as the integer 0".
Stroustrup, en effet, s'était rendu compte que la valeur 0, pour le
pointeur null en C, posait des problèmes sur certaines machines.

Dans le Working Draft, Standard for Programming Language C++ (4 octobre
2008), il est dit (§ 1.9- 4) :
Certain other operations are described in this International Standard as
undefined (for example, the effect of dereferencing the null pointer).
[ Note: this International Standard imposes no requirements on the
behavior of programs that contain undefined behavior. —end note ]


Mais si tu as un passage de la norme qui dit que ça *doit* provoquer
une erreur, je m'incline.

D'ailleurs, de mémoire, j'ai eu le problème sous Win95 ou Win98.

Si ca ne marche pas comme ca sous MacOS, c'est un bug de l'implementation.



Je ne pense pas.

Marc Boyer


Publicité
Poster une réponse
Anonyme