Discussion :

[chronos]

Bonjour,

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

Code :

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

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...

[Laurent Gomila]

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 :

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

1
2
3
4
5
void test_hello(test* this)
{
    std::cout<<"hello"<<std::endl;
}
test_hello(NULL);

[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.

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

[ram-0000]

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

Ou de tester this

Code :

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

1
2
3
4
if(this == NULL)
{
   ...
}

[chronos]

Effectivement, cette solution me plait bien ^^

Merci à vous

[Médinoc]

Ou rendre la fonction virtuelle...

[Laurent Gomila]

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

[nicroman]

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 !

[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é!

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 C++ :

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

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

[3DArchi]

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/

[Médinoc]

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

[3DArchi]

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.

[JolyLoic]

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é :

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.

[Jean-Marc.Bourguet]

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.

[JolyLoic]

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

Code :

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

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 :

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

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.

[loufoque]

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

[Médinoc]

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)...

[nicroman]

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 !

[loufoque]

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

[Obsidian]

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.