speicherallokierung und -freigabe...
-
Ich würde in deinem Fall auf das push_back lieber ganz verzichten, da es unter Umständen nicht das macht was man von ihm erwartet (übrigens dort < (zeilen_array-1)und nicht <=).
Überlade lieber operator[] oder erzeugen eine Memberfunktion wie at(). Da kann man auch eine Indexüberprüfung machen.
Statt push_back mit T* könnte man einen spezialisierten Konstruktor verwenden.
oder verwende gleich vector oder boost::array.
-
was meinst du mit "nicht das machen, was man erwartet"?
-
Ein push_back, z.Bsp. eines vector, hängt Elemente an das Ende deines Vectors an und allokiert bei Bedarf auch neuen Speicher (und kopiert dann). Wenn bei dir das Ende deines Arrays erreicht ist würde das letzte Element überschrieben.
Das meine ich damit.
-
achso, das wird bald weggecodet
, ich überleg nur wie man das ohne umkopieren machen kann!!!
-
exigoner schrieb:
noch irgendwelche ratschläge, fehler, verbesserungen, etc.
Lass die Überprüfung auf NULL vor delete weg, das ist Unsinn. Und lies dir meinen ersten Beitrag noch mal durch.
-
exigoner schrieb:
noch irgendwelche ratschläge, fehler, verbesserungen, etc.Lass die Überprüfung auf NULL vor delete weg, das ist Unsinn. Und lies dir meinen ersten Beitrag noch mal durch.
Was soll der erste Tip bringen?
In seiner Klasse gibt es doch nun beide Möglichkeiten, dass das Feld erstellt wurde oder halt nicht. Warum soll er da einfach die Überprüfung weglassen? Würde im letzter Fall ja die schon erwähnte Fehlermeldung bringen.
-
Würde es nicht.
Ein delete auf einen Nullpointer gibt keine Exception.
-
gut ok, aber hier is ein delete auf ein Feld, also []delete, und da bringt er zumindest bei mir auch bei nem NULL-Pointer ne Exception
-
cppLer schrieb:
gut ok, aber hier is ein delete auf ein Feld, also []delete, und da bringt er zumindest bei mir auch bei nem NULL-Pointer ne Exception
Blöd wenn sich was nicht an den Standard hält oder?
-
cppLer schrieb:
gut ok, aber hier is ein delete auf ein Feld, also []delete, und da bringt er zumindest bei mir auch bei nem NULL-Pointer ne Exception
Kann ich mit dem gcc 3.4 nicht bestaetigen.
-
cppLer schrieb:
Was soll der erste Tip bringen?
delete kann nicht fehlschlagen, new aber schon. Und wenn geanu dieser Fall in set_dim eintritt, ist sein Objekt "kaputt".
cppLer schrieb:
In seiner Klasse gibt es doch nun beide Möglichkeiten, dass das Feld erstellt wurde oder halt nicht. Warum soll er da einfach die Überprüfung weglassen? Würde im letzter Fall ja die schon erwähnte Fehlermeldung bringen.
Ich darf für dich mal den Standard zitieren
ISO/IEC 14882:2003(E) schrieb:
if the value of the operand of delete is the null pointer the operation has no effect
(5.3.5-2)
-
mmh, also lass ich die überprüfung weg, früher kam, da immer ne komische fehlermeldung...
jetz aber nicht mehr! trotzdem ist die überprüfung best. performance-verbessernd, oder?
-
exigoner schrieb:
mmh, also lass ich die überprüfung weg, früher kam, da immer ne komische fehlermeldung...
jetz aber nicht mehr! trotzdem ist die überprüfung best. performance-verbessernd, oder?Ich vermute, dass der delete-Operator eine solche Ueberpruefung einfach selber macht. Schliesslich hat er bei einem NULL-Pointer nichts zu tun. Wenn man diese nochmal darum setzt, wird der Compiler - mit etwas Glueck - diese Abfrage weg-optimieren.
-
if the value of the operand of delete is the null pointer the operation has no effect
bezieht sich das auch wirklich auf []delete ???
steht ja nur ohne Klammern da ... .
-
cppLer schrieb:
if the value of the operand of delete is the null pointer the operation has no effect
bezieht sich das auch wirklich auf []delete ???
steht ja nur ohne Klammern da ... .JA... delete[] kann gar keine Exception werfen:
void operator delete[](void* ptr, void*) throw();