Version imprimable
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.
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) :
Citation:
[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.]
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.Citation:
Envoyé par Goten
Mais tu le dis toi même tu as une UB, donc non ça démontre bien qu'on peut pas.. :s.
Ha oui d'accord, "in a well defined program" :D. 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.
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...
donc pour conclure:
int const &b=NULL;
donne provoque pas d'erreur niveau compilateur, mais c'est tout de même faux.
Non, le compilo refusera cette écriture, mais il acceptera celle-ciCode:int const &b=*(int const *)0;
Ou celle là, peut être plus claire pour deubelte :D
Code:
2
moi, je viens d'essayer, ca ne plante pas:Citation:
Non, le compilo refusera cette écriture, mais il acceptera celle-ci
int const &b=NULL;
j'ai aussi récemment découvert un qqch de nouveau dans le même style:
je connaissais:
mais pas:Code:int *a=new int[3];
la on crée réellement une variable, alors que dans le casCode:int *a=new int(3);
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.
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...
ok, cela revient à faire:
puisqu'à l'adresse pointée par s, on a 3.Code:
2
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.
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:
Alors où se trouve la pile (comment y accèder) (idem pour le tas, si bien sûr cela est possible)Code:
2
3
4
5
6
7
8
merci
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é.
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.Citation:
Qu'est ce que tu entend par code mémoire ? Le code compilé ?
>>C'est possible de faire cela avec visual C++?Citation:
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 que comme cela que jev ais comprendre les pointeurs/références...Citation:
M'enfin à moins de vouloir toucher de près à la compilation elle-même, ça ne devrais pas t'être d'une grande utilité.
Où donc dans visual studio ?Citation:
Envoyé par deubelte
J'ai vu un type le faire sous mon nez une fois, à toute vitesse, donc je suppose que oui :D.Citation:
Envoyé par deubelte
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.Citation:
Envoyé par deubelte
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.
Ben, tu fais ALT+6. (dans VC++2010)Citation:
Où donc dans visual studio ?
>je sais, mais c'est pour ma culture généraleCitation:
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.
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.
c'est quoi (en résumé) les registres?