[C++] Pourquoi et comment ce code fonctionne ?

Bonjour,

Quelqu'un peut il m'expliquer pourquoi ce code fonctionne ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include <iostream>   class test { public: void hello(); };   void test::hello() { std::cout<<"hello"<<std::endl; }     int main () { test * ptr = NULL; ptr->hello(); return 0; }

---

J'ai bien un "hello" sur la console...

La fonction test::hello() n'accède à aucune donnée de l'objet test, donc un appel de cette fonction sur une instance invalide aura de fortes chances de fonctionner.

Plus simplement, dis toi que le compilo va traduire ta fonction membre de cette manière :

Code:

---

1 2 3 4 5

void test_hello(test* this) { std::cout<<"hello"<<std::endl; } test_hello(NULL);

---

Je penssais à une chose dans le genre mais trop vraiment y croire. Du coup ma fonction hello n'est pas "crée" comme une fonction membre de ma classe, mais comme une bête fonction à la sauce C.

Question supplementaire, pour eviter ce genre de comportement, le seul moyen est de faire appel à une donnée membre ?

Citation:

---

Envoyé par chronos

Question supplementaire, pour eviter ce genre de comportement, le seul moyen est de faire appel à une donnée membre ?

---

Ou de tester this

Code:

---

1 2 3 4

if(this == NULL) { ... }

---

Effectivement, cette solution me plait bien ^^

Merci à vous

Ou rendre la fonction virtuelle...

Sauf que c'est pas vraiment à tes fonctions membres de s'assurer que this est correct.

Citation:

---

Envoyé par chronos

Je penssais à une chose dans le genre mais trop vraiment y croire. Du coup ma fonction hello n'est pas "crée" comme une fonction membre de ma classe, mais comme une bête fonction à la sauce C.

---

Heu... non.... tu confonds tout là...

Le code "machine" utilisé par le CPU n'a même pas la notion de "fonction".
Pour le CPU, il n'y a pas de fonction membre / fonction pas membre / statique ou autre... juste de la mémoire et une pile d'execution.

Quand à l'utilisation d'une donnée membre, aucune vérification ne sera faite non plus... le CPU va juste taper dans la mémoire autour de this (null) + offset... donc tu auras une exception genre: "illegal memory access to memory at 0x000000C"
L'utilisation d'une fonction virtuelle sera pareil, puisque le CPU ira taper dans la donnée membre à l'offset 0 (la table virtuelle).

Il n'y a pas moyen de se prémunir contre ce genre de mauvaise programmation hors du runtime, sauf à utiliser un vrai compilateur, qui va probablement te marquer le code ainsi écrit comme erreur (déréférencement de 'NULL'). En tout cas, VC9 me met une jolie erreur sur l'appel à Hello ! :D

En quoi l'appel d'une fonction non-virtuelle n'utilisant pas this est-il un déréférencement de pointeur nul ? Puisque le pointeur n'est justement pas déréférencé!

Je suis étonné que VC9 mette une erreur pour un type C++ natif, alors que la bibliothèque MFC elle-même emploie ce genre de stratagème pour certaines fonctions:

Code:

---

1 2 3 4

HWND CWnd::GetSafeHwnd() { return (this==NULL ? NULL : this->m_hWnd); }

---

PS: Est-ce une erreur d'éxécution ou de compilation ? Dans le cas d'une erreur d'exécution, se produit-elle aussi en mode Release ?

Edit: Notez qu'en .Net, appeler une méthode, virtuelle ou non, causera une NullReferenceException si la référence .Net est nulle.
http://blogs.msdn.com/oldnewthing/ar...6/4407029.aspx

Citation:

---

Envoyé par Médinoc

En quoi l'appel d'une fonction non-virtuelle n'utilisant pas this est-il un déréférencement de pointeur nul ? Puisque le pointeur n'est justement pas déréférencé!

---

Jette un coup d'oeil à http://www.developpez.net/forums/d61...uter/pointeur/

Mais ici, le pointeur est peut-être nul, mais il est initialisé dans tous les cas...

A mon avis, c'est un peu le même genre d'idée. Il suffit de mettre avant d'entrer dans la méthode une vérification ecx!=NULL. Il me semble qu'il y a sous visual une option pour ajouter un bout de code avant l'entrée dans une méthode. Peut-être que VC9 utilise ce genre de mécanisme. A confirmer par un expert de VC9.

Appeler une fonction membre non virtuelle sur un pointeur nul, ou un pointeur invalide, tant que l'on accède pas à une donnée membre de la classe me semble tout à fait valide.

Sinon, je vois mal comment delete this; pourrait marcher (surtout ce qui vient après).

Mais j'avoue ne pas trouver de standardese qui supporte ce cas... J'ai juste trouvé :

Citation:

---

Envoyé par 9.3.1/2

If a non-static member function of a class X is called for an object that is not of type X, or of a type derived from X, the behavior is undefined.

---

Mais ça parle du type de l'objet, pas de sa validité.
Je suis un peu perplexe.

3.7.3.2/4 -> The effect of using an invalid pointer value (including passing it to a deallocation function) is undefined
5.2.2/1 -> For a member function call, the postfix expression shall be an implicit (9.3.1, 9.4) or explicit class member access (5.2.5)
5.2.5/3 -> If E1 has the type “pointer to class X,” then the expression E1->E2 is converted to the equivalent form (*(E1)).E2;

L'appel est donc considéré comme un accès à un membre. Dans le cas du delete this, tant qu'on n'a pas d'accès à un membre (même fonction appelé implicitement), qu'est-ce qui poserait problème?

A nouveau, une des raisons pour rendre indéfinie toute utilisation de pointeurs invalides c'est que le fait de simplement les charger dans un registre peut poser problème pour certaines architectures -- faut pas aller très loin pour l'architecture, x86 suffit; il faut chercher plus pour trouver un OS qui fonctionne en mode protégé avec des segments, mais ça m'étonnerait fort qu'il n'y en ait pas.

En fait, la question que je me posais était la suivante :

Code:

---

1 2 3 4 5

class A { void f() {cout << "Hello";} void g() {delete this; f();} };

---

Dans ce cas, comme this ne sert à rien pour f, on pourrait imaginer qu'il soit supprimé de l'appel, et donc que le code reste valide. Mais je pense que ce serait difficile pour le compilateur de voir ça, et donc qu'on a préféré dire qu'il s'agit d'un comportement indéfini.

En fait, je crois que naturellement, je me serais trompé, et que j'aurais cru le code en question valide. Je suis un peu troublé par le fait que :

Code:

---

1 2 3 4 5

void A::g() { delete this; cout << "Hello"; }

---

Serait du code valide, alors qu'avec une fonction séparée, ce n'est plus le cas. Ce qui pourrait ressembler à un simple refactoring de type "extract method" change en fait la validité du code. Même s'il est vrai qu'un tel refactoring bien fait mettrait f en statique, et là, plus de problèmes.

Faire delete this de toutes manières c'est jamais très propre...

Mais pourtant nécessaire au comptage de références intrusif, dès que tu utilises des DLLs (la fonction de Release doit être membre et virtuelle)...

Ben je sais pas pour vous....
Mais pour moi valide, ca veut pas dire "qui compile et qui marche"....

Si je peux écrire dans le code { delete this; this->g(); } ou tout simplemenet { A* a = NULL; a->g(); } sans que le compilo me mette au moins un enorme warning (voir même l'IDE carrément en me soulignant le code en question en rouge), alors c'est que l'IDE en question a un *gros* probleme.

Je me fiche de savoir si g() accède ou non à des membres de l'objet, c'est pas mon problême, c'est celui de l'objet... Si jamais il lui vient l'idée de le faire, alors j'aurai de gros problêmes.... Et si la fonction en question n'accèdera jamais a des membres de l'objet, alors, elle doit être STATIQUE !

Le compilateur n'est pas en devoir de te signaler les comportements indéfinis que tu invoques...

Citation:

---

Envoyé par nicroman

Si je peux écrire dans le code { delete this; this->g(); } ou tout simplemenet { A* a = NULL; a->g(); } sans que le compilo me mette au moins un enorme warning (voir même l'IDE carrément en me soulignant le code en question en rouge), alors c'est que l'IDE en question a un *gros* probleme.

---

Dans l'absolu, ta méthode pourrait toujours accéder à this (sauf trap values, mais ça ne se produit pas sur PC).

Pour le reste, le compilateur ne peut pas te mettre un énorme avertissement car « A * a = NULL; » est séparé de « a->g(); ». Dans ton exemple, les deux instructions sont consécutives, mais elles pourraient être séparées de plusieurs lignes et dans l'intervalle, la valeur de « a » peut changer.

J'ai peut-être mal compris, mais je pense que NULL ne peut pas être une trap value de toute façon: Si c'était le cas, on ne pourrait pas lire un pointeur pour le comparer à NULL...

Citation:

---

Envoyé par Obsidian

Pour le reste, le compilateur ne peut pas te mettre un énorme avertissement car « A * a = NULL; » est séparé de « a->g(); ».

---

Tu serais surpris de ce dont est capable un compilateur :)

En attendant (et heureusement) les deux IDEs que j'utilisent m'avertissent tous sur le code:

Code:

---

1 2 3 4 5 6 7 8

A* a = null; .... if (xxxx) { a = .... } ... a->dosomething(); // <= "warning 'a' may be null"

---

Citation:

---

Envoyé par nicroman

Tu serais surpris de ce dont est capable un compilateur :)

---

Oui, je sais ! :-) Et dans ce cas précis, il en serait effectivement tout-à-fait capable, mais chaque chose en son temps ...