void reference?
-
du interpretierst ihn aber falsch.
-
mit der zeile
return *tmp;dereferenzierst du einen nullzeiger, zumindest darüber sind wir uns einig?
-
A macht was kaputt, so daß B nicht mehr funktioniert. Wo gehört jetzt das Oops hin? Da wo A was kaputt macht (meine Meinung) oder da wo jemand ahnungsloses versucht B trotzdem zu benutzen?
-
oline schrieb:
du interpretierst ihn aber falsch.
Wieso tust du mir nicht den Gefallen und begründest deinen Standpunkt.
davie schrieb:
dereferenzierst du einen nullzeiger, zumindest darüber sind wir uns einig?
Absolut. Null-Zeiger und nicht NULL, wie einige schrieben.
Und was entsteht laut Standard, wenn man dies tut? Darüber sind wir uns doch auch einig?
-
genau, undefiniertes verhalten.
damit ist alles, was später passiert egal.
-
groovemaster2002 schrieb:
1. das Dereferenzieren eines Null-Zeigers ergibt immer eine Null-Referenz - da is nix undefiniert dran
Dann lies mal
"a null reference cannot exist in a well-defined program"Was kann man daran falsch verstehen?
Weiters siehe 1.9p4
Certain operations are described in this International Standard as undefined (for example dereferencing the null pointer)
Das sind Sachen die man einfach nicht anders interpretieren kann.
btw: well-defined heisst: Programm mit definiertem verhalten - dies bedeutet, not well-defined ist ein "kaputtes" Programm
-
@Jester
Das oops gehört für mich dorthin, wo undefiniertes Verhalten in Erscheinung tritt (ich weiss, dass diese Antwort dich nicht glücklich machen wird
).davie schrieb:
genau, undefiniertes verhalten.
Nein, eben nicht. Es entsteht eine Null-Referenz. Punkt. Bis dorthin gibt es noch kein undefiniertes Verhalten. Alles was danach kommt bzw. mit dieser Null-Referenz angestellt wird, ist undefiniert.
@Shade
Ich würde ja gern was antworten. Nur kann ich deine Argumente nicht mehr ganz nachvollziehen. Nicht dass sie falsch wären, nur von meinem Standpunkt aus habe ich auch nichts anderes behauptet.
-
groovemaster2002 schrieb:
davie schrieb:
genau, undefiniertes verhalten.
Nein, eben nicht. Es entsteht eine Null-Referenz. Punkt. Bis dorthin gibt es noch kein undefiniertes Verhalten. Alles was danach kommt bzw. mit dieser Null-Referenz angestellt wird, ist undefiniert.
Erklaer mir bitte, wie du
"a null reference cannot exist in a well-defined program"
interpretierst.Ich verstehe dies so:
Eine "NULL Reference" kann es nicht geben - somit bedeutet jedes auftreten einer "NULL Reference" undefiniertes Verhalten. Denn der Standard legt fest, dass es eine "NULL Reference" nicht gibt, deshalb kann er nicht definieren was beim auftreten einer "NULL Reference" passiert, ergo ist es nicht definiert (undefiniert)Weiters interpretiere ich
"Certain operations are described in this International Standard as undefined (for example dereferencing the null pointer)"
folgendermassen:Einige Operationen sind undefiniert, darunter faellt auch das dereferenzieren eines NULL Zeigers.
char* tmp=NULL;
dies ist ein NULL Zeiger.*tmp;
dies ist eine Dereferenzierung.Da tmp ein NULL Zeiger ist, wird hier also ein NULL Zeiger derefrenziert, was mit undefiniertem Verhalten bestraft wird.
@Shade
Ich würde ja gern was antworten. Nur kann ich deine Argumente nicht mehr ganz nachvollziehen. Nicht dass sie falsch wären, nur von meinem Standpunkt aus habe ich auch nichts anderes behauptet.Meine Argumente sind Zitate aus dem Standard - mehr nicht.
Bitte interpretiere fuer mich die von mir zitierten Stellen. Fuer mich ist da eigentlich alles klar.
-
groovemaster2002 schrieb:
Das oops gehört für mich dorthin, wo undefiniertes Verhalten in Erscheinung tritt
Wenn also das Programm mit meinem Compiler trotz undefiniertem Verhalten korrekt läuft (es muß ja nicht immer abschmieren), dann gehört nirgends ein oops hin. Wenn ich dann nach 2 Jahren auf die neue Version des Compilers (oder einen andere Compiler) umsteige und da schmiert es ab, dann gehört ein oops hin. Hab ich das so richtig erfaßt?
Macht irgendwie keinen Sinn... aber das tut vieles nicht.MfG Jester
-
@groovemaster
undefiniertes verhalten ist aber undefiniert und muss nicht einmal in erscheinung treten.
-
groovemaster2002 schrieb:
Das oops gehört für mich dorthin, wo undefiniertes Verhalten in Erscheinung tritt (ich weiss, dass diese Antwort dich nicht glücklich machen wird
).Mir scheint du hast eine ganz spezielle Vorstellung von diesem "in Erscheinung treten", nämlich dass das Programm an dieser Stelle abstürzt oder ähnlich fatale Dinge. Diese Intuition stimmt aber nicht mit dem Standard überein. Der sagt, dass das Erzeugen einer Nullreferenz undefiniertes Verhalten auslöst, weil dort ein Nullpointer dereferenziert wird.
Das bedeutet im Klartext nichts anderes, als dass der Standard den Effekt offen läßt. 99,9% aller Compiler implementieren Referenzen vermutlich so, dass man Nullreferenzen erstellen kann. Na und, können sie doch machen. Undefiniert heißt ja eben, dass alles erlaubt ist, z.B. auch dass eine Referenz entsteht, die man nicht mehr in ein rvalue umwandeln kann, ohne einen Segfault zu kassieren. Egal, was danach passiert, das undefinierte Verhalten beginnt in dem Moment, in dem der Nullpointer dereferenziert wird.
-
Also sehen wir das doch mal theoretisch und praktisch.
Theoretisch:
Wenn der Compilerbauer bei der Zuweisung einer Referenz eine Prüfung auf NULL-Referenz durchführt und dann seine Telefonnummer in den Programmcounter lädt (was zu undefiniertem Verhalten führt), so wäre der Compiler dennoch standardkonform.Praktisch macht das natürlich kein Compilerbauer.
-
Bashar schrieb:
99,9% aller Compiler implementieren Referenzen vermutlich so, dass man Nullreferenzen erstellen kann.
Dann sind 99,9% aller Compiler in diesem Punkt standardkonform.
the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer
Jester schrieb:
Wenn also das Programm mit meinem Compiler trotz undefiniertem Verhalten korrekt läuft (es muß ja nicht immer abschmieren), dann gehört nirgends ein oops hin. Wenn ich dann nach 2 Jahren auf die neue Version des Compilers (oder einen andere Compiler) umsteige und da schmiert es ab, dann gehört ein oops hin. Hab ich das so richtig erfaßt?
Nein.
@Shade
Certain other operations are described in this International Standard as undefined (for example, the effect of dereferencing the null pointer).
An dem for example kann man schon sehen, dass hier keine detaillierte Erklärung der Problematik gegeben wird, sondern nur eine grobe Zusammenfassung. Also schaun wird uns die Details an.
a null reference cannot exist in a well-defined program
Das interpretiere ich so, dass ein Programm welches Null-Referenzen nutzt, undefiniertes Verhalten aufweist. Nicht aber, dass es keine Null-Referenzen gibt. Wie man sie erzeugt:
because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer
which causes undefined behavior.
Und genau dieses "object" an das die Null-Referenz gebunden wird, erzeugt undefiniertes Verhalten. Ich kann beim besten Willen nicht erkennen, dass das Dereferenzieren selbst undefiniert sein soll.
Diese 2 Stellen sind mir aus dem Standard bekannt, aber vielleicht gibts da ja noch andere, die ich übersehen hab.
-
durch das "would be" wird aber ausgedrückt, dass es der einzige weg, eine null referenz zu bekommen, das dereferenzieren eines null pointers wäre, das aber undefiniertes verhalten auslöst.
in der anderen stelle sagt der standard eindeutig, dass der effekt des derefenzieren eines null zeigers undefiniertes verhalten ist.
-
Kommt Leute, er hat's eigentlich schon lange kapiert.
-
Don't feed the troll.
-
groovemaster2002 schrieb:
a null reference cannot exist in a well-defined program
Das interpretiere ich so, dass ein Programm welches Null-Referenzen nutzt, undefiniertes Verhalten aufweist. Nicht aber, dass es keine Null-Referenzen gibt. Wie man sie erzeugt:
because the only way to create such a reference would be to bind it to the ?object? obtained by dereferencing a null pointer
which causes undefined behavior.
Und genau dieses "object" an das die Null-Referenz gebunden wird, erzeugt undefiniertes Verhalten. Ich kann beim besten Willen nicht erkennen, dass das Dereferenzieren selbst undefiniert sein soll.
Also nochmal ganz langsam:
"cannot exist" heisst "kann es nicht geben"
Und daran kann man nix falsch verstehen. es heisst "es gibt sie nicht", und wenn es etwas nicht gibt, kann man es auch nicht erstellen.
Wenn du eine 'NULL Reference' erstellst, dann nutzt die sie ja!would be - ist MÖGLICHKEITSFORM, wenn es also möglich wäre, würden sie schreiben:
the only way to create such a reference is to bind...das Dereferenzieren eines NULL Zeigers IST undefiniert. Da gibts keinen Kontext. Ich habe auf die schnelle nur diese eine Stelle im Standard gefunden - aber selbst diese ist doch wohl nicht falsch interpretierbar.
Einige Sachen sind undefiniert, zum Beispiel das dereferenzieren eines NULL Pointers.
Da steht nicht "zum Beispiel das dereferenzieren eines NULL Pointers in bestimmten Situationen", sondern es ist eine absolute Aussage - ohne Ausnahmen.
Oder zeig mir doch mal die Stelle im Standard wo steht, dass ich einen NULL Zeiger dereferenzieren darf.
Vielleicht solltest du nochmal darüber nachdenken. Es ist nicht lustig dir alles 100 mal zu erklären. Wenn du uns nicht glaubst, frag in comp.std.c++
-
Es wird wohl Zeit für die Merkbefreiung. Wer will?
Da steht eindeutig 'cannot exist'. Das mit 'kann es doch geben' zu übersetzen ist schon einigermaßen kreativ :p BTW hatte ich gemeint 99,9% aller standardkonformen Compiler, aber das spielt jetzt wohl auch keine Rolle mehr
-
int * foo = 0; // OK *foo; // Fehler!!! es wird NULL-dereferenziertFertig. Da bereits hier ein Fehler ist, ist es sinnlos darüber nachzudenken, ob man nicht eine Referenz erstellen könnte.
-
Nur mal so gedacht:
Wenn es die NULL-Referenz nicht geben würde, müsste ja nicht davor gewarnt werden.
Der Satz:
"In einer idealen Welt gibt es keinen Hunger" bedeutet ja auch nicht, dass es keinen Hunger gäbe. Sondern nur, dass wir keine ideale Welt haben.