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

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

  • M

    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 doch, §5.3.5/2

    0
  • L

    Michael E. schrieb:

    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 doch, §5.3.5/2

    muss ich mich wirklich selber quoten um zu zeigen, dass das nicht in widerspruch steht mit meiner aussage? tt

    0
  • A

    hilfe

    bitte löschts mein zweites Posting in diesem Thread
    und machts das Thema dicht.

    fühl mich irgendwie schuldig, dass das jetzt so ausartet 🤡

    0
  • M

    life schrieb:

    Michael E. schrieb:

    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 doch, §5.3.5/2

    muss ich mich wirklich selber quoten um zu zeigen, dass das nicht in widerspruch steht mit meiner aussage? tt

    Tu dir keinen Zwang an. Ich programmier auf jeden Fall nicht mit wahrscheinlich.

    0
  • S

    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.

    0
  • L

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

    0
  • S

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

    0
  • L

    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 🙂

    0
  • D

    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.

    0
  • L

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

    0
  • D

    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.

    0
  • S

    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.

    0
  • L

    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?

    0
  • C

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

    0
  • S

    CarstenJ schrieb:

    Aber das spornt ihn gerade an.

    Ja, leider 😞

    0
  • O

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

    0
  • P

    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

    0
  • N

    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 😃

    0
  • G

    net schrieb:

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

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

    0
  • N

    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

    0
Anmelden zum Antworten