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

[Shade Of Mine]

life schrieb:

trotzdem war eure argumentation natürlich falsch. Wenn man eine solche Aussage widerlegen möchte, muss man entweder emperische daten liefern, oder eine sinnvolle begründung bringen, warum es nicht gehen kann.

Haben wir: der Standard sagt "undefiniertes verhalten" das einzige was wir (bis zu Michael E.s Post nicht gemacht haben war, den Standard genau zu zitieren.

Es war sehr nett von Michael E und erwarte nicht, dass das immer fuer dich gemacht wird. Denn etwas im Standard nachschlagen kostet doch zeit die man idr nicht aufbringen will.

[life]

life schrieb:

life schrieb:

nur weil das verhalten undefiniert ist, heißt das nicht, dass es nicht wahrscheinlich das gleiche ergebnis haben würde, wie dein delete[]..

bezog sich auf den fehler in deiner logik:

HumeSikkins schrieb:

life schrieb:

wobei ein delete hier wahrscheinlich den gleichen effekt hätte oo

Nein. Hätte es nicht. ein delete hätte schlicht und einfach undefiniertes Verhalten.

deine aussage steht einfach nicht im widerspruch zu meiner, daher ist das "Nein" unbegründet (da die begründung keine begründung ist :>).

[Shade Of Mine]

life schrieb:

deine aussage steht einfach nicht im widerspruch zu meiner, daher ist das "Nein" unbegründet (da die begründung keine begründung ist :>).

Du machst dich laecherlich, denn 'wahrscheinlich' erzeugt es undefiniertes verhalten was 'wahrscheinlich' zu einem anderen Ergebnis fuehrt als 'den gleichen effekt'.

[life]

Shade Of Mine schrieb:

life schrieb:

deine aussage steht einfach nicht im widerspruch zu meiner, daher ist das "Nein" unbegründet (da die begründung keine begründung ist :>).

Du machst dich laecherlich, denn 'wahrscheinlich' erzeugt es undefiniertes verhalten was 'wahrscheinlich' zu einem anderen Ergebnis fuehrt als 'den gleichen effekt'.

die aussage mag richtig sein, aber es besteht kein zwingender kausaler zusammenhang zwischen dem undefinierten verhalten und dem tatsächlichen (compilerabhängigen) verhalten. Das ist schon ein Widerspruch in sich: Wenn es undefiniert ist, kannste keine definitive aussage darüber machen, ob das delete sich anderes verhält als ein delete[].
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". Und das kann durchaus falsch sein, wie ich schon zu bedenken gegeben habe

[davie]

suchst du jemanden, der dir sagt, dass das auf den meisten systemen wahrscheinlich deshalb nicht geht, weil da new[] mit hoher wahrscheinlichkeit noch die größe des arrays allerdings ohne eventuelle compilermagie irgendwo dazuspeicher-t/-n muss und delete ohne [] sich aber meistens wahrscheinlich nicht darum kümmert?

btw. undefiniertes verhalten mit "wahrscheinlich funktioniert es eh" gleichzusetzen ist wahrscheinlich immer gefährlich.

[life]

davie schrieb:

suchst du jemanden, der dir sagt, dass das auf den meisten systemen wahrscheinlich deshalb nicht geht, weil da new[] mit hoher wahrscheinlichkeit noch die größe des arrays allerdings ohne eventuelle compilermagie irgendwo dazuspeicher-t/-n muss und delete ohne [] sich aber meistens wahrscheinlich nicht darum kümmert?

sehr richtig. Das ist eine vernünftige begründung :>

[davie]

allerdings kümmert sich der standard nicht darum. da ist es einfach undefiniert. und undefiniert kann alles heißen.
(da wir hier im standard c++ forum compilerunabhängig reden und denken und unsere kleinen perfekten c++-compiler im kopf haben, heißt undefiniert für uns tatsächlich alles und das bedeutet, dass die wahrscheinlichkeit, dass es genau so funktioniert, wie es du wolltest, sehr nahe bei null liegt, denn es gibt unendliche viele möglichkeiten, was unser perfekter c++-compiler mit undefiniertem verhalten anstellen kann)
daher ist sowohl deine feststellung als auch meine antwort hier eigentlich fehl am platz. aber das passiert vielen, dass wissen, dass c++-forum hier gleichbedeutend mit standard/iso c++ ist.

also wenn es hier keine neuen fragen zum thema mehr gibt, würde ich einfach einmal darum bitten mit dieser sinnlosen diskussion aufzuhören. wer noch über sinn und unsinn "undefinierten verhaltens" und wahrscheinlichkeiten diskutieren will, kann das per mail machen.

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