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

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

[John Doe]

Wenn du den kompletten Thread gelesen hättest, du festgestellt das ich zum
einmal COM als Beispiel angeführt habe und
einmal COM als Antwort auf einen Frage angegeben habe.

Wenn das bei dir ständig ist hast wohl ein Problem mit Mengen- oder Grössenangaben, andernfalls solltest du vielleicht mal über deine Art
nachdenken.

Zu den diffusen Behauptungen habe ich immerhin ein Buch mit Autor angeführt,
das ist immerhin mehr als von dir gekommen ist. Aber das passt immerhin zu meiner
Vermutung das du den Thread nicht mal komplett gelesen hast bevor du deine
Solidaridäts-Postings abgelassen hast.

[Walli]

John Doe schrieb:

Zu den diffusen Behauptungen habe ich immerhin ein Buch mit Autor angeführt,
das ist immerhin mehr als von dir gekommen ist. Aber das passt immerhin zu meiner
Vermutung das du den Thread nicht mal komplett gelesen hast bevor du deine
Solidaridäts-Postings abgelassen hast.

Kurze Frage: Wie alt ist das Buch?

[John Doe]

2004

http://www.amazon.com/exec/obidos/ASIN/0735619670/qid=1104177775/sr=2-1/ref=pd_ka_b_2_1/002-7460024-6708846

Neben den positiven Bewertungen dort, findet sich im Buch auch Lob von Leuten wie:
- Jeffrey Richter
- John Vlissides
- Grady Booch
- u.a.

[Walli]

Und von wann ist deine Ausgabe? FYI, first edition:

winner of The software development jolt excellence award 1994

Ich habe nun doch mal in (More) Effective C++ und dem Struppi nachgelesen. Nirgendwo steht was davon, dass auf ein delete immer ein nullen des Zeigers folgen sollte, allerdings wird empfohlen, dass man Member-Pointer nullt wenn im Konstruktor noch kein Speicher dafür alloziiert wird. Das ist aber ein anderer Fall.