Aufruf von Funktionen auf Object an Adresse Null
-
mysterio schrieb:
ISO/IEC 14882:2003 schrieb:
If a nonstatic 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.Ich finde dies etwas unspezifisch. Wenn, unter der Annahme, dass es keine Member gibt bzw. in der Methode nicht auf Member zugegriffen wird, eine solche Methode aufgerufen wird, sollte es doch nicht undefiniert sein, weil Ihr Verhalten tendentiell eher einer statischen Methode oder einer freien Funktion entspricht.
Ist doch egal, wie Du das findest. Fakt ist: Der Standard definiert das so. Und wenn Du es trotzdem machst, dann fällt Dein Programm höchstwahrscheinlich früher oder später um.
Ich finde es auch sehr unspezifisch, das
typeid(T).name()alles Mögliche zurückgeben darf. Trotzdem ist es so, und daher ist die Funktion auch praktisch unbrauchbar.PS: Achso: Wenn Du Dir mal ansiehst, wie die Adressen von nicht-statischen Memberfunktionen aussehen, wird das vielleicht noch klarer.
-
Um mal von dem Problem etwas wegzukommen: Du willst eine Memberfunktion aufrufen, die keinerlei Membervariablen benutzt und zu keinem konkreten Objekt gehört. Warum nimmst du dann nicht eine statische Memberfunktion oder eine freie Funktion?
-
Tachyon schrieb:
PS: Achso: Wenn Du Dir mal ansiehst, wie die Adressen von nicht-statischen Memberfunktionen aussehen, wird das vielleicht noch klarer.
Dies haengt mit Sicherheit dann auch davon ab, um welche Funktionen es sich handelt. Wenn ich mal davon ausgehe, dass es sich um keine virtuellen handelt und welche die im einfach Vererbungspfad liegen, sollte es kein Problem bei der Aufloesung der Adresse geben.
SeppJ schrieb:
Um mal von dem Problem etwas wegzukommen: Du willst eine Memberfunktion aufrufen, die keinerlei Membervariablen benutzt und zu keinem konkreten Objekt gehört. Warum nimmst du dann nicht eine statische Memberfunktion oder eine freie Funktion?
Weil ich einen Typ und einen entsprechenden operator brauche.
In meinem Fall habe ich verschiedene Typ-Implementierung mit entsprechendem Operator und in bestimmten Konfigurationen wird der Typ mit der leeren inline Operatorumsetzung gewaehlt, damit der Optimierer den Code eliminieren kann.
Gruss
-
Wozu fragst Du eigentlich?
Der Standard sagt ganz klar, dass es UB ist. Wenn Dir das egal ist, dann frage ich mich, wieso Du fragst, was der Standard dazu sagt.Der Zugriff auf invalide Arrayindizes ist übrigens auch valides C++. Compiliert wunderbar auch mit wall, pedantic etc. Die Programme laufen häufig sogar wunderbar. Nur wenns knallt muss man sich halt auch nicht wundern.
-
Tachyon schrieb:
Der Zugriff auf invalide Arrayindizes ist übrigens auch valides C++.
Ist das nicht ein Widerspruch? Ich würde sagen, wenn etwas invalid ist, dann ist das auch kein valides C++..
Aber funktionieren tuts oft, ja.
-
drakon schrieb:
Tachyon schrieb:
Der Zugriff auf invalide Arrayindizes ist übrigens auch valides C++.
Ist das nicht ein Widerspruch? Ich würde sagen, wenn etwas invalid ist, dann ist das auch kein valides C++.
Invalide Programmlogik bitte nicht mit invalider Syntax verwechseln.
-
Mache ich nicht.
Aber wahrscheinlich schaue ich den Begriff undefiniert ein wenig zu Eng an. Würde aber meinen, dass der Standard durchaus auch eine Aussage macht, ob man das als "gültig" oder nicht anschauen kann.
Syntax ist ausser Frage korrekt, aber der Standard macht ja nicht nur über die Korrektheit der Syntax eine Aussage.
-
Lies das mal Undefined Behavior.
-
Tachyon schrieb:
Wozu fragst Du eigentlich?
Der Standard sagt ganz klar, dass es UB ist. Wenn Dir das egal ist, dann frage ich mich, wieso Du fragst, was der Standard dazu sagt.Zunaechst ja, der Standard sagt dies, was ich jetzt ja durch dich weiss und es ist mir nicht egal, weshalb ich ja auch gefragt habe.
Deshalb muss doch aber trotzdem die Frage erlaubt sein, ob dies, was der Standard sagt, auch immer richtig ist. Ich will jetzt keine Diskussion darueber los treten, ob der Standard dort falsch ist, aber fragen wird man doch mal duerfen, ob unter bestimmten Umstaenden die Formulierungen des Standards (obschon teilweise unspezifisch) auch immer gelten. Eben genau in diesem Fall, den ich geschildert habe. Ich wollte mich dabei nicht auf den Standpunkt stellen, dass wenn der Compiler es uebersetzt es richtig sein muss. Die Frage war ob es legal ist, Du/ihr hast/habt mir da geholfen und dies ist super, aber ich hatte halt noch weitere Fragen, wie man den Standard an dieser Stelle verstehen kann/muss und ob es da Spielraum gibt. Deshalb habe ich auch gewisse Randbedingungen spezifiziert unter denen meiner Meinung nach es kein unspezifiziertes Verhalten ist. Darueber wollte ich halt gern weiteres erfahren und nicht ob es generell unspezifiziert ist.
Gibt es dazu vielleicht noch Hinweise/Anmerkungen?
Danke auf jeden Fall schon mal fuer eure Hilfe.
-
Tachyon schrieb:
Lies das mal Undefined Behavior.
Ich weiss, was undefiniertes Verhalten ist.
Die Frage, die ich mir gestellt habe war eher, was du unter "valid" verstehst.
Syntaktisch? Ja, völlig korrekt.
Semantisch? Eher nicht.btw:
but GCC 1.21, upon finding a #pragma directive, would instead attempt to launch commonly distributed Unix games such as NetHack and Rogue, or start Emacs running a simulation of the Towers of Hanoi.[1]
:xmas1:
-
Ein Argument, was dem ganzen doch Gueltigkeit verleihen wuerde, waere meiner Meinung nach der placement new operator, welcher unter anderem im Betriebssystemkontext dazu verwendet wird Strukturen ueber Speicherbereiche zu legen (z.B. fuer memory-mapped I/O) und dann auf diesen mit einfachen Methoden zuzugreifen. Die Frage ist jetzt, wo der Unterschied zwischen der Konstruktion mit placement new und dem Setzen, wie im oberigen Beispiel liegt, wenn man annimmt, dass der Konstruktor (Standardkonstruktor) selbst nichts macht, folglich leer ist.
In diesem Fall haben wir ein ordnungsgemaess erzeugtes Objekt und demzufolge duerfte es hier kein undefiniertes Verhalten geben. Richtig?
Gruss
PS: Ich versuche, wie gesagt, nicht meinen oberigen Quelltext als richtig darzustellen, sondern ich will C++ sowie die betreffenden Fragen wirklich richtig durchdringen und verstehen.
