007
01.05.2007, 02:44 Uhr
Pablo
Supertux (Operator)
|
Zitat von Pler: |
Was bringt dein "Zwischenschritt" mit dem tmp-Zeiger? Wegen einer evtl. Freigabe wenn realloc nicht klappt?
|
Angenommen realloc funktioniert n Mal hintereinander. Beim n+1. Mal gibt realloc NULL, weil der Speicher nicht verschoeben/vergrößert/was_auch_immer/ werden kann. Ohne den temp = realloc Trick hättest du den Speicher "verloren", sprich die Adresse, wo der Speicher noch reserviert ist, damit entsteht ein Speicherleck. Außerdem würdest du die ganze Queue verlieren, d.h. wenn du ein Element nicht hinzufügen kannst, dann ist die ganze Liste weg. Das ist nicht im Sinne einer Queue, meiner Meinung nach.
Zitat von Pler: |
Und warum nach realloc nicht casten? Ich dachte, das soll man gerade machen? Und was hat das mit c++ dann zu tun?
|
In C muss man void* nicht casten, weil es implizit gemacht wird. Da malloc ein void* zurückliefert, braucht man malloc nicht zu casten. C++ ist da viel strikter als C, deswegen braucht man in C++ ein Cast vor malloc. Aber wenn man C++ benutzt, dann sollte man auch die C++ Mitteln nehmen, und diese sind new/delete, denn diese Bewirken auch, dass z.b. die Konstruktoren/Destruktoren bei Klassen aufgerufen werden. Ich bin jetzt nicht sicher, aber malloc/free würden das nicht tun, weil malloc/free nichts über Konstrukturen/Destruktoren wissen.
Zitat: |
Ne andere Möglichkeit wäre, ne Position einzuführen und ggf. halt Modulo zu rechnen - das bringt vor allem dann was, wenn Speicher knapp ist.
|
und/oder wenn man einen Ringbuffer schreibt.
@beey: ist es notwenig ein 0U, wenn man 0 mit einem size_t Element vergleicht? Imho ist 0U == 0. Oder hat es etwas mit unnötigen shift Operationen, die der Compiler beim Vergleichen erzeugen würde? -- A! Elbereth Gilthoniel! silivren penna míriel o menel aglar elenath, Gilthoniel, A! Elbereth! Dieser Post wurde am 01.05.2007 um 02:47 Uhr von Pablo editiert. |