void reference?

Bashar

Da würde mich ja interessieren, wie du das gemacht hast.

virtuell Realisticer

Bashar schrieb:

Da würde mich ja interessieren, wie du das gemacht hast.

Na das weisst du doch, war doch damals mit dir im chat und hatte den Code auch
irgendwo auf rafb gepostet gehabt...mal sehn ob ich den wiederfinde. Weiss noch,
dass der Borland-Compiler und der gcc den Code nicht geschluckt hat.

War glaub ich sowas in der Art:

int &i;

int j;

i = j;

Ich schau nochmal nach, ansonsten kann ich ja nochmal MSVC installieren und
das ganze nochmal machen.

Wenn jemand das Visual Studio.net 2002 hat, sollte er das Ganze nachvollziehen
koennen.

mfg
v R

groovemaster

davie schrieb:

Der Standard erwähnt sogar ausdrücklich, dass in einem legalen Programm Referenzen auf Null nicht vorkommen können - weil man sie eben nur erzeugen kann, wenn man einen Nullzeiger dereferenziert (8.3.2)

Der Standard spricht nicht von legalen, sondern von "well-defined
program". Und genau mit dieser Aussage bestätigst du, dass sich der Code so verhält, wie ers tut.

T* tmp = NULL;
    return *tmp;

Hier passiert nix undefiniertes. Es wird laut Standard eine null reference "erzeugt". Was damit passiert ist undefiniert (geb ja zu, dass dies nicht immer zu einem Absturz führen muss - auch wenn das auf x86 Plattformen die Regel sein wird). Mich störte nur, dass Shade schrieb:

b = 2;    // oops :-o //nein, hier kein oops

Wenn das Programm nicht irgendwo nach dem return sich undefiniert verhält, hier tut es das auf jeden Fall. Mir geht es aber nicht darum zu streiten, wo's oopst, sondern dass man die "sicheren" Referenzen auch missbrauchen kann.

Shade Of Mine

groovemaster2002 schrieb:

Hier passiert nix undefiniertes.

Soll ich dir den Standard vorlesen?

hier mal ganz langsam zum mitschreiben:

in particular, a null reference cannot exist in a well-defined program, 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.

Was ist daran unverständlich?
Wenn dir "well-defined" nicht gefällt, siehe 1.3.* - dort gibts n paar Erklärungen die du dir mal reinziehen solltest.

groovemaster

Sicherlich kann man den Satz unterschiedlich interpretieren, ich lese da 2 Fakten raus:
1. das Dereferenzieren eines Null-Zeigers ergibt immer eine Null-Referenz - da is nix undefiniert dran
2. die Auswirkungen durch die Benutzung einer Null-Referenz sind dagegen undefined, weshalb man sie in einem "well-defined" Programm nicht benutzen soll.

du interpretierst ihn aber falsch.

davie

mit der zeile

return *tmp;

dereferenzierst du einen nullzeiger, zumindest darüber sind wir uns einig?

Jester

@groovemaster:

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?

groovemaster

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?

davie

genau, undefiniertes verhalten.
damit ist alles, was später passiert egal.

Shade Of Mine

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

groovemaster

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

Shade Of Mine

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.

Jester

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

davie

@groovemaster
undefiniertes verhalten ist aber undefiniert und muss nicht einmal in erscheinung treten.

Bashar

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.

Geo

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.

groovemaster

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.

davie

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.

Jester

Kommt Leute, er hat's eigentlich schon lange kapiert.