void reference?
-
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.
-
Ich frage mich immer wieder, wie man über ein solches Thema 3 Seiten diskutieren kann...
Devil
-
Geo schrieb:
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.Richtig. Der Begriff «undefiniertes Verhalten» bezieht sich aber nunmal auf eine Idealwelt. Nämlich die, die die meisten der am Standardisierungsprozess beteiligten Parteien (Compilerhersteller, Benutzer, Toolhersteller ...) den kleinsten gemeinsamen Nenner darstellt. In der realen Welt, sagen wir unter Unix, ist die Dereferenzierung eines Nullpointers eine klare Sache. Das Programm bekommt ein SIGSEGV zugestellt und wird abgeschossen, Ende der Diskussion, 100% definiert. Unter MS-DOS wird je nach Speichermodell entweder der Interruptvektor 0 oder halt die Stelle 0 des aktuellen Segments ausgelesen oder verändert (uh oh!), Punkt. Der Z8 hat glaub ich an Adresse 0 seinen ersten IO-Port eingeblendet, da ruckt vielleicht der angeschlossene Schrittmotor los oder was weiß ich
Der C++-Standard will sich aber nicht aufbürden, das alles irgendwie zu definieren ... angenommen man würde fordern, dass dabei eine Exception generiert werden muss. Das würde bedeuten, dass jeder Zeigerzugriff geprüft werden muss, was der Performance nicht gerade zuträglich ist. Also lässt man den Effekt undefiniert und ist aus dem Schneider. Programmierer tun gut daran, sowas zu umschiffen und sich nicht auf die «Laune» die ihr Compiler gerade an den Tag legt zu verlassen, zumindest wenn sie Wert auf Portabilität legen.
</pamphlet>
-
Bashar schrieb:
Es wird wohl Zeit für die Merkbefreiung.
Ganz meine Meinung. Ich denke aber, dass der Gedanke reicht. Ein tatsächliches Posten der Merkbefreiung ist nicht nötig. Ich mach hier zu und dann ist ruh'!