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

[Shade Of Mine]

life schrieb:

Wenn es undefiniert ist, kannste keine definitive aussage darüber machen, ob das delete sich anderes verhält als ein delete[].

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. Genauso hier - es mag auf deinem VC++ funktionieren, aber einen schoenen gegenbeweis mit dem gcc wurde schon gebracht (und gcc ist verbreiteter als VC++ ;))

Meine Aussage hingegen, war definitiv nicht definitiv (;)). So sagte ich: 'Wahrscheinlich hat es den gleichen effekt', was eindeutig miteinschließt, dass es auf einigen (wenigen) compilern einen anderen effekt haben kann. Worüber man hier streiten kann ist das "einige wenige".

Nur dass es nicht "wahrscheinlich" den selben effekt hat sondern "moeglicherweise, aber meistens nicht".

Oft wird es nicht abstuertzen, aber dennoch wirst du in diesen Faellen ein Memory Leak haben.

aber bitte: gib auf, deine argumentation ist laecherlich bzw. nicht vorhanden und du hast hier wohl alle Forumsgroessen (davie, Hume, Daniel E.,...) gegen dich.

[life]

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

Genauso hier - es mag auf deinem VC++ funktionieren, aber einen schoenen gegenbeweis mit dem gcc wurde schon gebracht (und gcc ist verbreiteter als VC++ ;))

wenn du weniger zeit mit deinem lächerlichen me > you gehabe verbringen würdest, und einfach mal lesen würdest, was ich schreibe hättest du schon so manche interessante information erhaschen können: So hab ich schon eingeräumt, dass es bei mir auch nicht funktioniert, und dass die Aussage so nicht haltbar ist. Aber das passt vielleicht nicht in dein schwarz-weiß denken...

aber bitte: gib auf, deine argumentation ist laecherlich bzw. nicht vorhanden und du hast hier wohl alle Forumsgroessen (davie, Hume, Daniel E.,...) gegen dich.

was soll ich aufgeben? ist das ein wettbewerb?

[CarstenJ]

aber bitte: gib auf, deine argumentation ist laecherlich bzw. nicht vorhanden und du hast hier wohl alle Forumsgroessen (davie, Hume, Daniel E.,...) gegen dich.

Aber das spornt ihn gerade an. Ich verstehe ehrlich gesagt nicht, wieso der Mist hier noch offen ist. Es gab schon Threads, die wurden wegen sehr viel weniger dichtgemacht. 4 Seiten für ein Problem, das schon nach dem 3. Post gelöst wurde.

[Shade Of Mine]

CarstenJ schrieb:

Aber das spornt ihn gerade an.

Ja, leider

[otze]

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

und trotzdem würde ein guter mathematiker,der seinen kontostand genau kennt, nicht darauf wetten

und so ähnlich ist es ja auch hier, es kann sein, dass der compilerhersteller delete genauso wie delete[] implementiert, dann hast du genau recht, aber andererseits könnte sich der compilerhersteller sagen:"der standard sagt, dass es undefiniert ist, also ignoriere ich diesen fall einfach zugunsten der höheren performance"-und schon haste verloren.
Und im endeffekt kommt es auch nur darauf an, was der standard sagt, aufm gcc hilfts dir auch nicht, wenn der code in deiner hand für den bcb geschrieben wurde, bei dem man ja kein typename in templates braucht...

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