🚀 go-pugleaf

In article <0YZ8BLIJ@wuschel.ibb.schwaben.com> uz@wuschel.ibb.schwaben.com (Ullrich von Bassewitz) writes:

   Ist es legal, non-virtual Funktionen ueber ein Nicht existierendes Objekt
   (NULL) aufzurufen und dann in der Member Function den Fall abzuhandeln, dass
   der this Pointer NULL ist?

   D.h. sowas wie

       Aufruf:

	   Window* W = NULL;
	   ...
	   Window->Write ("...");


       In der Member Function:

	   if (this == NULL) {
	       // Object pointer is NULL, do nothing
	       return;
	   }


   Dass es mit virtuellen Funktionen nicht tut ist mir klar, dass es bei nicht
   virtuellen Funktionen tut ist mir genauso klar. Die Frage ist, kann ich da
   in irgendwas reinlaufen, weil das Verhalten evtl. undefiniert ist bei
   anderen/zukuenftigen Compilern?

Das wird u.a. im ARM (9.3 "Member Functions"/p176) als ungueltig erklaert.
Man kann diese Technik damit zwar noch als zusaetzlichen Test im Programm
verwenden, kommt aber um die Abfrage _vor_ dem Aufruf nicht herum.

	Enno

Hallo Ullrich...

Ich wuerde sagen, unter DOS springt dein Programm ins Nirvana, da 
es versucht, an Adresse 0x0000:0000 die Klassenstruktur incl. 
Methodentabelle zu finden, irgend eine Adresse (z.B. 0x0000:001B) als 
Zeiger auf deine Methode interpretiert und dann losspringt... CRASH!!!
Unter Windows oder OS/2 bekommst Du eine Protection Fault vor den Latz 
geknallt, wenn dein Programm an 0x0000:0000 versucht auf ein Segment bzw. 
eine Speicherseite zuzugreifen, die ihm nicht gehoert. Ein schlauer 
Compiler koennte den Versuch, auf eine Klassenmethode an 0x0000:0000 
zuzugreifen vielleicht abfangen, aber was dann?
Von so her kann ein this-Pointer schon NULL sein, aber es kann nichts 
gescheites dabei herauskommen.
In diesem Sinne

Joern
 

Joern Ihlenburg (joern.ihlenburg@student.uni-tuebingen.de) wrote:
> Ich wuerde sagen, unter DOS springt dein Programm ins Nirvana, da 
> es versucht, an Adresse 0x0000:0000 die Klassenstruktur incl. 
> Methodentabelle zu finden, irgend eine Adresse (z.B. 0x0000:001B) als 
> Zeiger auf deine Methode interpretiert und dann losspringt... CRASH!!!

Nein, das tut mit allen mir bekannten Compilern - deshalb wollte ich ja auch
wissen, ob es legal ist. Wo es nicht geht sind virtuelle Funktionen, weil
diese ueber die VMT angesprungen werden, aber virtuelle Methoden hatte ich
ja explizit ausgeschlossen.

Gruss


        Uz


-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

Hallo Ullrich,

Sorry, ich habe mich geirrt. Du hast Recht, ich bin der Sache mit einem 
Debugger nachgegangen. Solange die Elementfunktion nicht virtuell ist und 
nicht auf ein Datenelement zugegriffen wird, ist die Sache voellig legal.
Ich zitiere aus "Die C++ Programmiersprache" von B. Stroustrup:

"Jeder Element-Funktion wird ein Zeiger auf das Objekt, fuer das die 
Elementfunktion aufgerufen wurde, als verborgenens Funktionsargument 
uebergeben. Auf dieses implizierte Argument kann vermittels 'this' 
explizit zugegriffen werden. In jeder Funktion einer Klasse 'X' ist ein 
Zeiger 'this' implizit als

 X *const this;

deklariert, der zum Zeitpunkt des Aufrufs der Element-Funktion mit der 
Adresse des Objekts initialisiert wird."

Wenn sich alle Compilerhersteller an diese Definition von Stroustrup 
gehalten haben, sehe ich da kein Problem, da 'this' zur Elementfunktion 
und nicht zur Klasse gehoert.

Joern Ihlenburg



-----8<---------------------------------------------------------------

 eMail: joern.ihlenburg@student.uni-tuebingen.de

---------------------------------------------------------------------- 

Joern Ihlenburg (joern.ihlenburg@student.uni-tuebingen.de) wrote:
> Sorry, ich habe mich geirrt. Du hast Recht, ich bin der Sache mit einem 
> Debugger nachgegangen. Solange die Elementfunktion nicht virtuell ist und 
> nicht auf ein Datenelement zugegriffen wird, ist die Sache voellig legal.
> Ich zitiere aus "Die C++ Programmiersprache" von B. Stroustrup:

Ich wuerde mich hier Enno anschliessen (ich hab's inzwischen nachgelesen).
Im ARM (9.3) steht: "The effect of calling a nonstatic member function
(9.4) of a class X for somewhat that is not an object of class X is
undefined."

Da die Dereferenzierung eines NULL Zeigers wohl zweifelsohne "not an object
of class X" ist, sind die Auswirkungen so undefiniert, auch wenn es
normalerweise funktioniert.

Gruss


        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com