T * ptr = new T[1] => delete ptr oder delete[] ptr ??

[phlox81]

life schrieb:

Shade Of Mine schrieb:

Doch. Es heisst: es macht irgendwas.
Es ist wie wenn du einen Wuerfel wirfst und behauptest es kommt "2". Klar, ab und zu wird es passen, aber jeder Mathematiker wird dir bestaetigen, dass das Ergebnis nicht vorherbestimmbar ist.

das ist richtig. Aber nehmen wir man du summierst die augenzahl von 10 wurfen, so wäre es durchaus sinnvoll zu behaupten, dass beispielsweise ein wertebereich von 25-45 ziemlich wahrscheinlich ist...

Sollen wir es ins Mathematikforum verschieben ?

Wenn es im Standard undefiniert ist, ist das Verhalten wohl auch
mit einer gewissen Wahrscheinlichkeit undefinierbar...

Devil

[net 0]

für einfache structs, usw. nehmt doch besser 'malloc' und 'free' und für c++ objekte sowas wie 'auto_ptr', da ist dann 'delete oder delete[]' keine frage mehr

[Grober]

net schrieb:

da ist dann 'delete oder delete[]' keine frage mehr

std::auto_ptr funktioniert doch gar nicht für Arrays.

[net 0]

Grober schrieb:

net schrieb:

da ist dann 'delete oder delete[]' keine frage mehr

std::auto_ptr funktioniert doch gar nicht für Arrays.

oh, schade... muss man dann das array in ein objekt packen oder ein typedef draus machen? aber es gibt doch bestimmt auch was, was mit arrays geht

[phlox81]

boost kann auch arrays als smartpointer

[Daniel E.]

net schrieb:

Grober schrieb:

net schrieb:

da ist dann 'delete oder delete[]' keine frage mehr

std::auto_ptr funktioniert doch gar nicht für Arrays.

oh, schade... muss man dann das array in ein objekt packen oder ein typedef draus machen?

Das Analogon zu auto_ptr ist im wesentlichen vector.
Und bloß kein Array-Typedef, es ist einfach gräuselig; typedef macht dir nämlich *keine* neuen Typen, auch wenn der Name so klingt. Bsp:

typedef int foo[23];

void f() {
    int *p = new foo; /* hier wird `new int[23]' aufgerufen,
      also ist der zurückgelieferte Zeiger ein `int*' und kein `foo*' */

    /*  */

Gelöscht werden muß dieser Zeiger übrigens auch wieder mit delete[], nicht mit delete obwohl man im Quelltext keinen Aufruf von new[] sieht. Besonders häßlich ist das dann, wen man nur mal schnell was prototypen will und später dann foo zu einer echten Klasse ausbaut, mit op[] usw.

[roan312]

Hi, mir will das noch nicht so recht einleuchten, wenn man einen Pointer auf eine Array hat ist das doch nur der Pointer auf das erste Element dieses Arrays.
Wieso soll es dann Failed sein, das erste Element eines Arrays mit einem Element zu löschen?
Das sollte doch weder Speicherlecks noch sonst Irgendwas geben.

MfG RoaN;

[otze]

roan312 schrieb:

Hi, mir will das noch nicht so recht einleuchten, wenn man einen Pointer auf eine Array hat ist das doch nur der Pointer auf das erste Element dieses Arrays.
Wieso soll es dann Failed sein, das erste Element eines Arrays mit einem Element zu löschen?
Das sollte doch weder Speicherlecks noch sonst Irgendwas geben.

MfG RoaN;

bist du dir sicher, dass der compilerhersteller new so implementiert, wie dus denkst?

könnte new den speicher nicht so anlegen?

1  |2  |3  |4  |5  |6  |7<--Bytes
sizeof(array)  |array

mit anderen worten: vor der position des zeigers legt der compiler einen integer ab, der die größe des nächsten mit new[] angelegten blocks angibt.in dem fall würde delete(falls es diese größen angabe ignoriert) den speicher der für die größe des arrays vorgesehen ist, nicht freigeben-> speicher leck

der compilerhersteller könnte auch für new und new[] zwei separate lookuptables benutzen, in dem fall würde bei benutzung des falschen delete[] ein absolutes chaos ausbrechen, weil für den zeiger kein speicher in der new liste vermerkt ist.

[roan312]

Da wirst du recht haben, ich hatte vergessen, dass der operator new[] ja auch noch die Größe des Arrays braucht, um es wieder zu löschen.
Hatte ich sowieit auch schonmal gelesen, aber bist du sicher, dass der Integer für die Größe direkt vor dem Array liegt?
Ich dachte immer der wäre einfach Irgendwo.

MfG RoaN;

[Shade Of Mine]

roan312 schrieb:

Hatte ich sowieit auch schonmal gelesen, aber bist du sicher, dass der Integer für die Größe direkt vor dem Array liegt?

Hängt von der Implementierung ab, und dieser Ansatz ist simpel und problematisch.

Ich dachte immer der wäre einfach Irgendwo.

Wo denn zb?
möglich ist natürlich eine lookuptable für die adressen, was zu debug zwecken zwar super ist, weil du mit sicherheit sagen kannst ob dieses delete jetzt passt und welche adressen noch nicht freigegeben wurden, aber es hat den overhead einer lookuptable der nur zu debug zwecken vorteile bringt.

oder denkst du an andere sachen? mag natürlich auch andere gute implementationen geben, aber dieser ansatz mit größer vor dem speicherblock ist gut.

[roan312]

Ne ich dachte jetzt eigendlich an Garnichts
Keine Ahnung wo sonst, stand in dem Buch halt nur nicht drinne und ich wollte sichergehen.

MfG RoaN;