Oh mein Gott! Ich habe Windows gekillt! ;-)

[DrGreenthumb]

John Doe schrieb:

Was ist an dieser einen zusätzlichen Zeile (p = 0;) chaotisch ? Oder meinst du die
Überprüfungen ?

nee, ich meinte die Tatsache, dass bei dir keiner weiß ob der Pointer gültig ist oder nicht.

Das ist für mich Chaos.

In C++ lässt sich die Lebenszeit von Objekten doch gut regulieren, dank Destruktoren.
Ich meine, schon klar dass es in der Praxis vielleicht nicht immer so rosig aussieht, aber generell sollte man das zumindest versuchen und nicht auf gut glück die Zeiger auf Null setzen weil man keinen Plan mehr hat, was das Programm eigentlich so tut.

[Shade Of Mine]

John Doe schrieb:

sondern um zu vermeiden das irgendwo in meinem Programm Pointer rumliegen von
denen keiner weiss ob sie ungültig sind oder nicht.

und sobald du diese situation hast, hast du fehler im programm - weil das einfach nicht passieren _darf_.

Für mich ist das genau der gleiche Automatismus mit dem ich Pointer auch mit
0 initialisiere. Wenn ein Pointer 0 ist, dann ist er ungültig ansonsten ist er
gültig.

Das ist eine falsche annahme. Ein Zeiger auf 0 ist sehr wohl gueltig. es heisst: ich zeige gerade auf nichts. es heisst aber auch: ich bin voll lebendig.

waehrend ein wilder zeiger heisst "ich bin tod, wer mich anfasst ist necrophil".

Wenn ein Program mehr als 100 nicht triviale Klassen enthält die ausserdem
(oft) zueinander in Bezug stehen dann behälst auch du ganz sicher nicht den Überblick
welcher Pointer zu einem bestimmten Punkt der Laufzeit gültig ist.
Immer in der Annnahme das du Pointer nicht nur funktionslokal verwendest.

Warum nicht? die beziehungen untereinander sind ja egal - weil ich leicht an den invarianten der Klasse A erkennen kann, welche Werte der Zeiger haben darf. das ist ein Blick - und da member sowieso private sind, sind mir die beziehungen egal.

Was ist an dieser einen zusätzlichen Zeile (p = 0) chaotisch ? Oder meinst du die
Überprüfungen ?

du verstehst es nicht
du ueberspielst damit logikfehler.

aber ich glaube ich hoere jetzt auf...

[John Doe]

Wenn ich einen Pointer als Member habe dann muss das nicht bedeuten das der
Pointer ausschliesslich im Destruktor zerstört wird. Warum nicht als Folge
irgendeiner anderen Operation. Das heist es kann während der Existenz eines
Objekts vorkommen das eine (Pointer)-Member ungültig ist.

Aber OK, Einigung wenn du du nicht mehr glaubst das 0-setzen aller Pointer
ein sicheres Zeichen geistiger Verwirrung darstellt.

mfg JJ

[Shade Of Mine]

John Doe schrieb:

Das heist es kann während der Existenz eines
Objekts vorkommen das eine (Pointer)-Member ungültig ist.

du liest einfach nicht, was ich schreibe

[DrGreenthumb]

John Doe schrieb:

Wenn ich einen Pointer als Member habe dann muss das nicht bedeuten das der
Pointer ausschliesslich im Destruktor zerstört wird. Warum nicht als Folge
irgendeiner anderen Operation. Das heist es kann während der Existenz eines
Objekts vorkommen das eine (Pointer)-Member ungültig ist.

ich sach ja, Chaos pur :xmas2:

das 0-setzen aller Pointer ein sicheres Zeichen geistiger Verwirrung darstellt.

ich glaube, das beschreibts ganz gut

[John Doe]

Ich glaube deine Vorstellung von einem Softwareprojekt ist etwas zu idealistisch.
In einem Team von 30 - 50 Entwicklern die Komponenten erstellen die miteinander
interagieren wirst du diese Wissen um "Pointer ist tot" nicht an jeder Stelle
zur Verfügung haben.

Wenn ich in meiner Komponente eine Funktion habe die eine Pointer übergeben bekommt dann prüfe den Wert diese Pointers ab melde falls notwendig, dieses als
Fehler, damit die anderen Entwickler reagieren und Änderungen vornehmen können.

Das ich euch meinen Standpunkt nicht darlegen kann, schade , aber auch kein Weltuntergang. Zumindest machens auch andere Leute so, die lange und erfolgreich
(praktisch) Software entwickeln, daher bleib ich dabei.

mfg JJ

[Walli]

John Doe: Bloß weil es gemacht wird muss es nicht sinnvoll sein. Wenn man in einem Team arbeitet, dann schrauben in den seltensten Fällen 2 Leute an der gleichen Klasse herum. Das Klasseninterface sollte im Idealfall IMHO so gestaltet sein, dass der Anwender der Klasse nichts mit raw pointers zu tun hat, also erübrigt sich das nullsetzen in den meisten Fällen, da man innerhalb einer Klasse ganz gut überblicken kann wo welcher Pointer wie benutzt wird.

[Shade Of Mine]

John Doe schrieb:

Wenn ich in meiner Komponente eine Funktion habe die eine Pointer übergeben bekommt dann prüfe den Wert diese Pointers ab melde falls notwendig, dieses als
Fehler, damit die anderen Entwickler reagieren und Änderungen vornehmen können.

Bitte versuch wenigstens einmal zu lesen und zu verstehen was ich geschrieben habe. das tut mir langsam naemlich echt weh.

niemand ist gegen checks oder defensives programmieren. darum geht es hier garnicht.

wenn jemand einen kaputten zeiger uebergibt (NULL ist ein gueltiger zeiger) dann ist sein code kaputt.
und ich bin dafuer, dass man solche fehler aufdeckt.

genau darum geht es. nicht um das checken von fehlern, sondern darum, dass ein NULL zeiger ein gueltiger zeiger ist und ein wilder zeiger nicht.
wenn irgendwo ein wilder zeiger auftaucht, ist der code kaputt. einfach einen NULL zeiger daraus machen, macht die sache nur schlimmer. weil das programm laeuft, als waere alles ok - dabei hat jemand den zeiger aus versehen geloescht.

nun kann ein null zeiger aber ein legaler wert sein und es wird weiter gearbeitet, obwohl der aufrufer glaubt einen zeiger auf ein objekt zu uebergeben. der aufgerufene bekommt aber einen null zeiger. er meldet den fehler nicht, weil es durchaus OK sein kann NULL zeiger zu uebergeben (das ist ja einer der unterschiede zwischen referenz und zeiger).

man hat nun einen bug im programm, den man vertuscht.

bei mir wuerde in dieser situationen der debugger anspringen und mir zeigen "hier ist ein ungueltiger zeiger". bei dir laeuft das programm durch und hat zB nur ein andere ergebnis und vielleicht nichteinmal das (beim testen treten solche fehler ja nie zu tage, sondern erst, wenn die software beim kunden ist :()

meine variante ist also die "sichere", weil fehler entdeckt werden (sofern man testet - wenn man nicht testet, sind beide variante gleich mies, weil der fehler unetdeckt bleibt)

[John Doe]

Bei COM-Programmierung lassen sich Raw-Pointer zumindest als Parameter
nicht vermeiden. Wenn Leute, die seit mehr als 10 Jahren Software entwickeln
und es auch schon zu erfolgreichen Buchveröffentlichungen gebracht haben, soetwas
,inklusive Begründung, empfehlen dann hat das, insbesondere wenn ich diese
Begründung aus eigener praktischer Erfahrung nachvollziehen kann, durchaus Sinn,
für mich.

Nochmal ganz zum Anfang Ausgangssituation:
- Eine Klasse mit verschiedenen Member-Variablen, darunter mindestens ein
Pointer
- Eine Memberfunktion wird aufgerufen, diese bewirkt das dieser Pointer gelöscht
wird.
- Eine weitere Memberfunktion wird aufgerufen. Diese benötigt zur Verarbeitung
diesen Pointer.
a.) Beim Löschen wurde der Pointer auf 0 gesetzt. Ein simples assert wird für
den Entwickler oder die QA deutlich anzeigen das hier ein ungültiger
Pointer übergeben wurde.
b.) Beim Löschen wurde der Pointer nicht 0 gesetzt. Eine direkte Überprüfung ist
nicht möglich, die Funktion beginnt ihre Arbeit, beim Aufruf von weiteren
Unterfunktionen wird dieser Pointer als Parameter weitergeben. Irgenwann
einmal knallt es, im günstigsten Fall direkt wenn der Pointer halt ungültig
ist. Aber eben "weit unten auf dem Stack". Aber, praktisch schon
vorgekommen, an der bewussten Speicheradresse
befindet irgendetwas gültiges, nun vielleicht probiert man hiermit dann ein
delete, dann kommt aber richtig Freude auf.

Haltet mich für stur, aber mir gefällt Variante a besser.

mfg JJ

[operator void]

Soll ich noch auto_ptr und scoped_ptr in die Diskussion einwerfen? Die nullen zwar intern, aber ich finde nichts Falsches daran und habe mit ihnen auch bisher nie Probleme gehabt - auch nicht in komplizierteren Situationen.

[Coward]

Hi Shade of Mine,

Mache ich nur, wenn der Zeiger selber state anzeigt. Also zB bei einem smartpointer, wenn zeiger==NULL wird auf nix gezeigt.

würdest du den auch Zeiger auf den Referenzzähler (legt man ja immer am Heap an) eines shared_ptr's auf 0 setzen?

[Shade Of Mine]

John Doe schrieb:

Bei COM-Programmierung lassen sich Raw-Pointer zumindest als Parameter
nicht vermeiden. Wenn Leute, die seit mehr als 10 Jahren Software entwickeln
und es auch schon zu erfolgreichen Buchveröffentlichungen gebracht haben, soetwas
,inklusive Begründung, empfehlen dann hat das, insbesondere wenn ich diese
Begründung aus eigener praktischer Erfahrung nachvollziehen kann, durchaus Sinn,
für mich.

Ich habe mein wissen natuerlich vom Penner um die Ecke und noch nie professionell programmiert und auch keine Beispiele und Begruendungen genannt.

a.) Beim Löschen wurde der Pointer auf 0 gesetzt. Ein simples assert wird für
den Entwickler oder die QA deutlich anzeigen das hier ein ungültiger
Pointer übergeben wurde.

operator void schrieb:

Soll ich noch auto_ptr und scoped_ptr in die Diskussion einwerfen? Die nullen zwar intern, aber ich finde nichts Falsches daran und habe mit ihnen auch bisher nie Probleme gehabt - auch nicht in komplizierteren Situationen.

Warum verdammt nochmal liest keiner meine Beitraege??

Coward schrieb:

Hi Shade of Mine,

Mache ich nur, wenn der Zeiger selber state anzeigt. Also zB bei einem smartpointer, wenn zeiger==NULL wird auf nix gezeigt.

würdest du den auch Zeiger auf den Referenzzähler (legt man ja immer am Heap an) eines shared_ptr's auf 0 setzen?

Ja, endlich versteht mich jemand.
Natuerlich wuerde ich das - weil der Zeiger einen state reflektiert. 0 bedeutet auf kein Objekt zeigen.

gerade bei einer smart pointer klasse _kann_ es in _keiner situation_ zu einem wilden pointer kommen.

ich rede die ganze zeit vom unterschied 0-zeiger und wilder zeiger.

[John Doe]

Natuerlich wuerde ich das - weil der Zeiger einen state reflektiert. 0 bedeutet auf kein Objekt zeigen.

Und genau diesen state hat, meines Erachtens, jeder Pointer. Unter gewissen
Umständen ist dieser state vernachlässigbar, insbesondere wenn man mit Smartpointern
arbeitet. Wenn man das jedoch nicht kann, oder will, oder was auch immer, dann
sollte diese state, meiner Meinung nach, jederzeit überprüfbar sein.

Natürlich ist ein NULL-Pointer erlaubt. Aber in meinen Programmen ist die Logik
nummal üblicherweise so, das wenn ich einen NULL-Pointer bekomme dann ist der
für mich "leer". Und wenn ein Pointer da leer ist wo ich einen "vollen" erwarte
und genauso umgekehrt, dann ist das genau die Fehlersituation die abfangen will.
Und diese Vorgehensweise ist halt nur dann machbar wenn man delete und 0-setzen
zusammen hält.

mfg JJ

[Walli]

John Doe schrieb:

Und wenn ein Pointer da leer ist wo ich einen "vollen" erwarte
und genauso umgekehrt, dann ist das genau die Fehlersituation die abfangen will.

Diese Fehlersituation soll aber im Endprodukt nicht eintreten und demnach muss sie auch nicht abgefangen werden. Du holst dir nur den Teufel ins Boot wenn du offensichtliche Fehler schon frühzeitig ignorierst. Wenn der Pointer keinen State haben soll, dann ist ständiges nullen IMHO ein Zeichen von Faulheit. Man riskiert eine vermurkste Programmlogik, bloß damit die Tester später keinen Absturz protokollieren und man u.U. noch mal an den Code ran muss.

[Unix-Tom]

Um das mal klarzustellen: Auch WinXP kann man zu einem Absturz bringen. z.B. mit Treiber. Das kein Bluescreen kommt liegt einfach daran das dieser nicht mehr angezeigt wird und Windows neu startet.
Kann man aber deaktivieren.

[Shade Of Mine]

John Doe schrieb:

Natürlich ist ein NULL-Pointer erlaubt. Aber in meinen Programmen ist die Logik
nummal üblicherweise so, das wenn ich einen NULL-Pointer bekomme dann ist der
für mich "leer".

Dann wuerde ich an deiner stelle mal referenzen verwenden.
was bringen zeiger die nicht 0 sein koennen?

Und wenn ein Pointer da leer ist wo ich einen "vollen" erwarte
und genauso umgekehrt, dann ist das genau die Fehlersituation die abfangen will.

Dann spricht nichts gegen 0.
Aber mir hoert ja sowieso keiner zu

auch wenn ich das oft schreibe - es ist nunmal so. Sonst wuerdet ihr nicht davon ausgehen, dass ich etwas gegen 0 zeiger habe.

Und diese Vorgehensweise ist halt nur dann machbar wenn man delete und 0-setzen
zusammen hält.

Aber die probleme die du dir damit einhandeln kannst, willst du nichteinmal kommentieren, gell?

ich fasse es noch ein letztes mal zusammen, damit verlasse ich diesen thread:
einen zeiger immer 0 zu setzen kann zu folgendem Problem fuehren: 0 zeiger und ungueltiger zeiger sind verschiedene sachen. ungueltig heisst: wilder zeiger.
wenn ich nun sage, dass alle ungueltigen zeiger 0 sind - habe ich das problem, dass ich zwischen einem gewollten 0 und einem 'passierten' 0 (also eigentlich einem wilden, fehlerhaften zeiger) nicht unterscheiden kann. das programm verarbeitet den falschen zeiger aber 'korrekt' so was waere er ein 0 zeiger. der caller denkt aber, dass der zeiger auf etwas zeigt (warum sonst, sollte er einen wilden zeiger haben) und die programmlogik ist zerstoert.

Mal abgesehen davon, dass wenn man 2 zeiger auf ein objekt hat und einen zeiger deleted, der andere immer noch auf 'etwas' zeigt - diese 0 setzen methode also keinen falls perfekt ist.

ich habe _nie_ gesagt, dass ein zeiger nicht 0 sein darf oder dass das 0 setzen nach einem delete bloedsinn ist oder sonst etwas anderes als das oben genannte.

Ich versuche nur darauf hinzuweisen, dass ein zeiger 3(!) zustaende hat:
an, aus, kaputt
und dass kaputt != aus ist

sobald kaputt vorkommt (auch wenn man es mit aus ueberschrieben hat) hat man einen logikfehler.

was natuerlich nicht heisst, dass jeder zeiger den man deleted hat, kaputt ist.

[John Doe]

Dann wuerde ich an deiner stelle mal referenzen verwenden.
was bringen zeiger die nicht 0 sein koennen?

Schon mal versucht einen Interface-Pointer in der COM-Programmierung mittels
Referenz zu übergeben.

Warum verdammt nochmal liest keiner meine Beitraege??

Wenn der Pointer kaputt ist er kaputt und nicht "aus", wenn er "aus" (= deleted ?!) ist, ist er, bei mir, = 0. Doch noch Einigung

mfg JJ

[Walli]

John Doe schrieb:

Dann wuerde ich an deiner stelle mal referenzen verwenden.
was bringen zeiger die nicht 0 sein koennen?

Schon mal versucht einen Interface-Pointer in der COM-Programmierung mittels
Referenz zu übergeben.

Komm doch nicht ständig mit COM. Dass das Design schlecht ist wird wohl allgemein bekannt sein, aber diesen Stil in einem C++ Forum zu bewerben, bloß weil COM das so macht halte ich für mehr als fragwürdig. Klar muss man manches Mal in den sauren Apfel beißen wenn man auf COM und Co. angewiesen ist, aber dieser Stil sollte sich IMHO nicht durch ein ganzes Projekt ziehen.

[John Doe]

Komm doch nicht ständig mit COM. Dass das Design schlecht ist wird wohl allgemein bekannt sein, aber diesen Stil in einem C++ Forum zu bewerben, bloß weil COM das so macht halte ich für mehr als fragwürdig. Klar muss man manches Mal in den sauren Apfel beißen wenn man auf COM und Co. angewiesen ist, aber dieser Stil sollte sich IMHO nicht durch ein ganzes Projekt ziehen.

Einfach mal den kompletten Thread lesen dann musst du auch nicht mehr so einen
Sch*** schreiben.

[Walli]

COM-Interfaces sind scheiße und sollten IMO deswegen gewrappt werden wo es nur geht (bzw. es vom Aufwand her sinnvoll ist). Im Verlaufe des Threads hast du immer irgendwelche diffusen Behauptungen aufgestellt warum man ständig raw-Pointer benutzen, bzw. nach dem delete immer stur nullen sollte und dich dann immer das Thema auf COM o.ä. umgeschwenkt, wenn man Argumente dagegen gebracht hat.
Und zu deiner Art verkneife ich mir mal jeden Kommentar...