spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wenn man den Zeiger aber auf NULL setzt, dann weiß man nicht das man etwas falsch gemacht hat. Also das hat alles seine Vor- und Nachteile...

Meistens ist genau der Wert NULL das Signal, dass etwas schief gegangen ist. Für mich ist der wichtigste Vorteil, dass der NULL-Zeiger keine Seiteneffekte erzeugen kann, wenn man ihn aus Versehen verwendet, sondern kontrolliert abstürtzt.

Zitat von »Moe«

sondern kontrolliert abstürtzt

Und genau da irrst du dich. Die Benutzung eines 0-Zeigers ist undefiniert. Dein Programm kann crashen oder ohne Probleme weiterlaufen. Beide Fälle passieren in der Regel auch.

Ich verwende 0-Zeiger nie um anzuzeigen, dass etwas schief gelaufen ist, sondern als regulären Wert, der eben das bedeutet: Kein Objekt verknüpft. 0-Zeiger benutze ich also by design. Das passiert dann eigentlich immer als Argument einer Funktion, wo man optional ein Objekt angeben kann, dass dann etwas macht. Wenn man einen Zeiger als Daten-Member hat, dann sollte da wahrscheinlich auch ein Smart Pointer her (Weak reference z.B.).
Die Aussagen in dem Thread mögen vielleicht so wirken, dass Zeiger nie 0 sein sollten, aber das ist wohl nicht gemeint, sondern man sollte sich anders benutzen. Gemeint ist aber aber wohl hauptsächlich: Mach keine manuelle Speicherverwaltung, sondern benutz Smart Pointer, passende Container etc., etc.

Zitat von »drakon«

Und genau da irrst du dich. Die Benutzung eines 0-Zeigers ist undefiniert. Dein Programm kann crashen oder ohne Probleme weiterlaufen. Beide Fälle passieren in der Regel auch.

Falsch. Ein Zugriff auf NULL-Speicher ist eben nicht undefiniert sondern führt zum Absturz. Mir ist auch noch nie untergekommen, dass dereferenzieren oder andere Pointeroperationen auf NULL nicht abgestürtzt wären. NULL steht eben für "kein gültiger Speicherbereich" und jede Laufzeitumgebung muss das mit einem Absturz quittieren - außer man fängt die Exception.
Eine Ausnahme sind arithmetische Funktionen, dann rechnet man ja mit Integern und erzeugt einen theoretisch gültigen Zeiger.
Viele Libs prüfen auf NULL-Pointer, deswegen stürtzt da nichts ab.

NULL verwende ich auch, wenn ich einen Parameter "ausschalten" will. Aber wie soll eine Funktion, die ein Objekt anlegen soll, anzeigen, dass es eben nicht geklappt hat? Jetzt sag nicht Exceptions...

Zitat

Die Aussagen in dem Thread mögen vielleicht so wirken, dass Zeiger nie 0
sein sollten, aber das ist wohl nicht gemeint, sondern man sollte sich
anders benutzen. Gemeint ist aber aber wohl hauptsächlich: Mach keine
manuelle Speicherverwaltung, sondern benutz Smart Pointer, passende
Container etc., etc.

Der Thread klingt so, als ob alle Smart-Pointer verwenden und in letzter Zeit nicht viel mit Pointern gemacht haben...

Einfach mal etwas behaupten, ja..
Wenn du es mir nicht glaubst, dann lies es doch selbst im Standard nach:

Zitat von »8.3.2/4«

Note: 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.

Es wäre auch völlig hirnrissig Absturz vorzuschreiben, daher: Undefiniertes Verhalten, weil jeder Compiler Hersteller in dem Fall machen kann was er will.

Zitat von »Moe«

Ein Zugriff auf NULL-Speicher ist eben nicht undefiniert sondern führt zum Absturz. Mir ist auch noch nie untergekommen, dass dereferenzieren oder andere Pointeroperationen auf NULL nicht abgestürtzt wären. NULL steht eben für "kein gültiger Speicherbereich" und jede Laufzeitumgebung muss das mit einem Absturz quittieren - außer man fängt die Exception.

Dazu hat drakon ja schon alles gesagt.

Zitat von »Moe«

Eine Ausnahme sind arithmetische Funktionen, dann rechnet man ja mit Integern und erzeugt einen theoretisch gültigen Zeiger.

Genaugenommen kann es sogar allein schon beim Ausrechnen ungültiger Zeiger theoretisch zu undefiniertem Verhalten kommen, da braucht man noch nichtmal drauf zugreifen...

Zitat von »Moe«

Aber wie soll eine Funktion, die ein Objekt anlegen soll, anzeigen, dass es eben nicht geklappt hat? Jetzt sag nicht Exceptions...

Wieso nicht?

Zitat von »Moe«

Der Thread klingt so, als ob alle Smart-Pointer verwenden und in letzter Zeit nicht viel mit Pointern gemacht haben...

Smartpointer sind kein Ersatz für Pointer. Wer das glaub, hat Smartpointer nicht verstanden.

Zitat

drakon

Es wäre auch völlig hirnrissig Absturz vorzuschreiben, daher:
Undefiniertes Verhalten, weil jeder Compiler Hersteller in dem Fall
machen kann was er will.

Okay, mein Fehler, ich wollte eigentlich auf NULL-Speicherzugriffe hinaus - ich wollte auch schon editieren, aber ihr habt meinen Fehler sofort aufgedeckt.

Zitat

dot
Wieso nicht?

Weil es immer wieder Projekte gibt, die vorschreiben, sie nicht zu verwenden. Und es gibt Compiler/Plattformen, die das gar nicht erst unterstützen...

Nun, wir gingen davon aus, dass du den Zugriff auf ein Objekt über einen Nullpointer meinst. Oder was genau verstehst du unter einem "NULL-Speicherzugriff"?

Zitat von »Moe«

Zitat

dot
Wieso nicht?

Weil es immer wieder Projekte gibt, die vorschreiben, sie nicht zu verwenden. Und es gibt Compiler/Plattformen, die das gar nicht erst unterstützen...

Ja, z.B. in Embedded Systems, hard real-time Computing oder der untersten Schicht eines Betriebssystem Kernels, sind Exceptions oft aus technischen Gründen tatsächlich keine Option!? Das heißt aber noch lange nicht, dass man sie im Allgemeinen nicht verwenden kann oder gar meiden sollte...

Zitat von »dot«

Nun, wir gingen davon aus, dass du den Zugriff auf ein Objekt über einen Nullpointer meinst. Oder was genau verstehst du unter einem "NULL-Speicherzugriff"?

Ich meinte den schreibenden Zugriff:


Sowas signalisiert der Prozessor als Fehler und da ist mir noch nie untergekommen, dass das Betriebssystem nicht die Anwendung abgeschossen hat, bzw. kein Segfault-Signal geschickt hat, das im Standardfall (ohne Handler) die Anwendung abschießt. Aber wenn ich darüber nachdenke, ist es nicht C++, das für den Fehler sorgt und ich hab da wohl ein paar Sachen verdreht...

Null ist für die CPU eine perfekt gültige Adresse. Allerdings wird kaum ein Betriebssystem dort Speicher mappen, weshalb man in der Tat wohl praktisch immer mit einer Access Violation rechnen kann. Das ist imo auch eines der sinnvolleren Argumente für das Nullsetzen von Zeigern nach delete. Ich bin trotzdem der Meinung, dass man schon dabei ist, etwas falsch zu machen, wenn sich überhaupt nur die Gelegenheit ergibt, darüber nachzudenken, ob man einen Zeiger nach delete nun auf Null setzen soll oder nicht...