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

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.

John Doe

Wie oben angegeben Ausgabe 2004

Das mit dem Member-Pointer seh ich genauso. Das ist ja genau die Ausgangssituation
für meine Argumentation. Das "lokale" Pointer relativ ungefährlich sind hab ich
ja ebenfalls schon angeführt.
Um das zu vermeiden sollte man wo immer möglich Smartpointer verwenden und Parameter
per Referenz übergeben.
Wenn man das aber nicht will oder kann (COM ),
ist mir zumindest in langen Jahren noch kein Fall begegnet wo diese Vorgehensweise
zu Problemen geführt hat.

CSS

Artchi schrieb:

Tja, wie wir "denken" sollen ohne Sourcecode oder nähere Hinweise, ist mir schleierhaft. CSS hat genug Postings auf dem Zähler, das er weiß, wie man eine Frage hier stellt. Hellsehen können wir nicht... abgesehen davon, das ich NT5.x für ziemlich absturzsicher halte. Ich weiß nicht mal, ob es unter NT5.x einen Bluescreen gibt, da ich in all den Jahren keinen gesehen habe.

Was hat er gemacht? Hat er einen Treiber geschrieben? Wir wissen NICHTS!

Jeder hier weiß nur eines: er hat NT5.x ca. 30x zum Absturz gebracht. Und jetzt?

in meinem Post steht das ich die Arbeit mit Zeigern lerne, wie soll ich da einen Treiber schreiben?

MfG CSS

DrGreenthumb

und wie hastes jetzt zum abstürzen gebracht?

vielleicht ja so'n lustiger bug wie printf("\r\r\b") oder was das mal mit dem VC++ war

hehejo

Ich hoffe es stört keinen, wenn ich den Thread noch einmal aufwärme und meinen Senf dazu packe!

//Ich denke mal, es ist vollkommen ok auf einen NULL-Pointer zu prüfen:

int blablub(const int* a) : throw (DumbProgrammerException) 
{ 
  if(!a)
   throw DumbProgrammerException("you gave me an NULL-Pointer; bad boy");

  return ++(*a);
}
//##############################//

//Aber das mit NULL setzen nicht sowas gemeint ist (- gemacht werden soll):

void machwas(int* a)
{
  if(!a)
    return;
  ++(*a);
}

int main()
{
  int* pa = new a;
  *pa = 4;

  machwas(pa);

  delete pa;
  pa = 0;

  // nochmal pa benutzen, obwohl wir ihn schon abgeschrieben haben.
  machwas(pa); // <- LOGIK-Fehler fällt nicht mehr auf.
  // Hätten wir den Pointer nicht auf 0 gesetzt, wäre er noch wild
  // und das Programm würde abschmieren...
  // ~> Wir merken, dass wir einen wilden Pointer genutzt haben und 
  // überdenken unserere Logik!

  return 0;
}