Différence entre char &r='c' et char r='c'

**deubelte** · 04/03/2010, 12h31

je suis un d'accord avec camboui. Je n'ai pas vos expériences, mais je ne vois pas en quoi le code d'une telle fonction

double &f(int o){
....
}

qui renvoie une référence est invalide.

Il n'est pas écrit ici:
[ame]http://en.wikipedia.org/wiki/Undefined_behavior[/ame]

que le déférencement d'un pointeur nul est une UB.

**Goten** · 04/03/2010, 12h48

Forcément si une UB est quelque chose d'acceptable alors tu peux faire passer beaucoup de chose ...
On "peut" accéder à une case d'un tableau qui existe pas ...

Bon et je recite la norme (parce que c'est quand même la norme) :

[Note: in particular, a null reference cannot exist in a welldefined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bitfield.]

**jblecanard** · 04/03/2010, 13h16

Envoyé par Goten

Forcément si une UB est quelque chose d'acceptable alors tu peux faire passer beaucoup de chose ...
On "peut" accéder à une case d'un tableau qui existe pas ...

Hé oui, on peut, et ça fait un beau segfault. J'ai testé pas plus tard que ce matin. peut être que ça dépend du compilo. J'ai testé sur mon visual studio au taf.

**Goten** · 04/03/2010, 13h19

Mais tu le dis toi même tu as une UB, donc non ça démontre bien qu'on peut pas.. :s.

**jblecanard** · 04/03/2010, 13h26

Ha oui d'accord, "in a well defined program"

. Mais dans la pratique, C++ permet de faire un programme sale ou une référence sura NULL. Certes, si le boulot est fait proprement, ça n'arrive pas.

**Goten** · 04/03/2010, 13h55

C'est là que je suis pas d'accord, il le permet pas puisqu'il plante...
Un systéme qui crash j'appelle pas ça permettre...

**deubelte** · 04/03/2010, 15h04

donc pour conclure:
int const &b=NULL;

donne provoque pas d'erreur niveau compilateur, mais c'est tout de même faux.

**camboui** · 04/03/2010, 15h20

Non, le compilo refusera cette écriture, mais il acceptera celle-ci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int const &b=*(int const *)0;

**jblecanard** · 04/03/2010, 15h22

Ou celle là, peut être plus claire pour deubelte

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int * p = NULL;
int& r = *p;

**deubelte** · 04/03/2010, 15h50

Non, le compilo refusera cette écriture, mais il acceptera celle-ci

moi, je viens d'essayer, ca ne plante pas:
int const &b=NULL;

j'ai aussi récemment découvert un qqch de nouveau dans le même style:
je connaissais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int *a=new int[3];

mais pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int *a=new int(3);

la on crée réellement une variable, alors que dans le cas
int a=3; on ne "crée" pas de variable.

C'est à dire que si on accède dans une fonction à la variable a, dans le premier cas on pourra changer sa valeur, mais pas dans le deuxième cas.

**Goten** · 04/03/2010, 15h52

avec un new int[] tu crées un tableau. Avec new int (3) tu alloues un int et à l'adresse pointé l'int contiendra trois...

**deubelte** · 04/03/2010, 15h59

ok, cela revient à faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 int p=3;
  int *s=&p;

puisqu'à l'adresse pointée par s, on a 3.

**jblecanard** · 04/03/2010, 16h03

Pas tout à fait deubelte, car avec un new, ton int sera alloué sur le tas et non sur la pile, et ne sera par conséquent pas détruit sans un delete explicite (et ça sera moins performant tout ça tout ça).

D'un point de vue algorithmique, c'est pareil, mais au niveau de la gestion mémoire à la compilation, il y a une vraie différence.

**deubelte** · 04/03/2010, 16h35

oui, exact, d'ailleurs, est-il possible de savoir si on a alloué un objet sur le tas ou sur la pile en étudiant la mémoire?
par exemple, ceci est le code mémoire

0x00B21420 55 8b ec 81 ec f4 00 00 00 53 56 57 8d bd 0c ff ff U.ì.ìô...SVW...ÿÿ
0x00B21431 ff b9 3d 00 00 00 b8 cc cc cc cc f3 ab 6a 04 e8 32 ÿ.=...¸ÌÌÌÌó«j.è2
0x00B21442 fd ff ff 83 c4 04 89 85 14 ff ff ff 83 bd 14 ff ff ýÿÿƒÄ....ÿÿÿƒ..ÿÿ
0x00B21453 ff 00 74 1a 8b 85 14 ff ff ff c7 00 03 00 00 00 8b ÿ.t....ÿÿÿÇ......
0x00B21464 8d 14 ff ff ff 89 8d 0c ff ff ff eb 0a c7 85 0c ff ..ÿÿÿ...ÿÿÿë.Ç..ÿ
0x00B21475 ff ff 00 00 00 00 8b 95 0c ff ff ff 89 55 f8 c7 45 ÿÿ.......ÿÿÿ.UøÇE
0x00B21486 ec 03 00 00 00 8d 45 ec 89 45 e0 33 c0 52 8b cd 50 ì.....Eì.Eà3ÀR.ÍP
0x00B21497 8d 15 b8 14 b2 00 e8 db fb ff ff 58 5a 5f 5e 5b 81 ..¸...èÛûÿÿXZ_^[.

de la fonction:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void main(){
 
  int *a=new int(3);
 
  int p=3;
  int *s=&p;
 
}

Alors où se trouve la pile (comment y accèder) (idem pour le tas, si bien sûr cela est possible)
merci

**jblecanard** · 04/03/2010, 16h41

Oui c'est possible, mais ça commence à être poussé là...

Qu'est ce que tu entend par code mémoire ? Le code compilé ? Si tu veux observer le comportement de la pile et du tas, il vaut mieux lancer ton programme en débug dans un outil adapté, pour observer l'évolution de la mémoire au runtime, la pile et le tas n'existant concrètement qu'au runtime.

M'enfin à moins de vouloir toucher de près à la compilation elle-même, ça ne devrais pas t'être d'une grande utilité.

**deubelte** · 04/03/2010, 16h52

Qu'est ce que tu entend par code mémoire ? Le code compilé ?

J'appelle le code mémoire ce qu'on voit dans le tableau que j'ai envoyé. C'est ce qu'on voit dans visual studio d'ailleurs.

il vaut mieux lancer ton programme en débug dans un outil adapté, pour observer l'évolution de la mémoire au runtime, la pile et le tas n'existant concrètement qu'au runtime.

>>C'est possible de faire cela avec visual C++?

M'enfin à moins de vouloir toucher de près à la compilation elle-même, ça ne devrais pas t'être d'une grande utilité.

>>C'est que comme cela que jev ais comprendre les pointeurs/références...

**jblecanard** · 04/03/2010, 16h56

Envoyé par deubelte

J'appelle le code mémoire ce qu'on voit dans le tableau que j'ai envoyé. C'est ce qu'on voit dans visual studio d'ailleurs.

Où donc dans visual studio ?

Envoyé par deubelte

>>C'est possible de faire cela avec visual C++?

J'ai vu un type le faire sous mon nez une fois, à toute vitesse, donc je suppose que oui

.

Envoyé par deubelte

>>C'est que comme cela que jev ais comprendre les pointeurs/références...

Tu vas loin là quand même. Déjà parce qu'au niveau assembleur, une référence est un pointeur. C'est juste que C++ va s'occuper tout seul de savoir quand il faut le déréférencer ou pas. La notion de référence n'existe plus au niveau assembleur.

De plus, la problématique de l'allocation de la mémoire entre la pile et le tas est complètement distincte de la notion de référence et de pointeur.

**deubelte** · 04/03/2010, 17h13

Où donc dans visual studio ?

Ben, tu fais ALT+6. (dans VC++2010)

De plus, la problématique de l'allocation de la mémoire entre la pile et le tas est complètement distincte de la notion de référence et de pointeur.

>je sais, mais c'est pour ma culture générale

**camboui** · 04/03/2010, 17h30

Ce que tu appelles le "code mémoire" n'est pas très instructif...
Essaie plutôt ctrl+F11, c'est le code assembleur. Ça c'est utile, ça permet de comparer du code Release avec du code Debug, les optimizations, etc

Il y a aussi une autre fenêtre pour voir le contenu des registres, etc.

**deubelte** · 04/03/2010, 17h57

c'est quoi (en résumé) les registres?

Différence entre char &r='c' et char r='c'

C++

Discussions similaires

Partager

Partager