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

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