T * ptr = new T[1] => delete ptr oder delete[] ptr ??
-
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[]..
Das ist nicht der Punkt. Undefiniertes Verhalten ist undefiniert. Jedes Programm das undefiniertes Verhalten enthält ist kein legales C++ Programm.
Es ist völlig müßig statitistische Erhebungen durchzuführen zumindest aus Sicht von Standard-C++.Natürlich könntest du ein Experiment mit x verschiedenen Compilern machen und schauen wie sich diese x Compiler in dieser Situation verhalten. Nur was bringt es dir? Nix. Denn erstens kann sich jeder andere Compiler anders verhalten und zweitens kann es sein, dass jemand die globalen Operator new/delete-Funktionen überlädt und dann stehst du da wieder ohne Ergebnis.
Wenn du dich schon auf eine konkrete Ausprägung von undefiniertem Verhalten verlässt, dann solltest du jeden Compiler und jede Compilerversion mit der du arbeitest einzeln checken. Und einen Fehler ausspucken, wenn dein Programm auf einem von dir nicht getesteten Compiler übersetzt wird. Oder deinen Hack zumindest gut dokumentieren.
Das alles ist hier aber nicht nötig, da die richtige Lösung einfach so nahe liegt und völlig unproblematisch ist.
-
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[]..
Du legst dich mit dem falschen an
-
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 :>).
-
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 :>).
Deine Aussage ist imo übheraupt keine Aussage sondern lediglich ein Stochern im trüben Teich. Sie hat, so wie du sie hingeschrieben hast, überhaupt keine Basis auf der sie sich begründen lässt.
Auf der einen Seite hast du den Effekt eines deletes auf einem Array wie er für Standard-C++ undiskutierbar festgelegt ist (darüber sprach ich) und auf der anderen Seite hast du beliebig viele mögliche Implementationen eines konkreten Effekts.
Sinnvolle Aussagen (neben der die sich auf Standard-C++ bezieht) sind imo solche Sachen wie: "Compiler X in Version Y verhält sich unter der Annahme das die eingebauten Funktionen verwendet werden immer so". Oder: "Compiler X in Version Y implementiert dynamische Speicherverwaltung so, daraus ergibt sich...". Oder: "Nach dem ich die folgenden 34 Compiler getestet habe ergibt sich folgende Statistik: "Was hast du von einem Satz: "wobei ein delete hier wahrscheinlich den gleichen effekt hätte oo"? Selbst wenn du eine Statisttik hättest die dein wahrscheinlich belegt hilft dir das wenig in dem Moment wo du einen Compiler verwendest der in solch einem Fall einfach deine Festplatte formatiert.
-
du redest von begründeten aussagen. Aussagen müssen aber nicht zwangsläufig begründet sein. Und nicht begründete Aussagen müssen auch nicht zwangsläufig falsch oder sinnlos sein.
-
life schrieb:
du redest von begründeten aussagen. Aussagen müssen aber nicht zwangsläufig begründet sein. Und nicht begründete Aussagen müssen auch nicht zwangsläufig falsch oder sinnlos sein.
Klar. Man kann auch ohne Begruendung im recht sein, keine Frage.
Aber was aendert es daran, dass du im unrecht bist? Du kannst es begruenden oder nicht begruenden wie du willst, falsch bleibt falsch.
-
bisher hat noch keiner meine aussage widerlegt. Wie kommst du darauf, dass sie falsch ist?
-
life schrieb:
bisher hat noch keiner meine aussage widerlegt. Wie kommst du darauf, dass sie falsch ist?
Wenn du Hume und mir nicht glaubst, dann lies es im Standard nach.
Ich (und ich nehme an, die meisten anderen auch) haben keine grosse Lust jede Aussage im Standard nachzuschlagen um den Absatz zitieren zu koennen. Wir wissen manche sachen einfach.
Undefiniertes Verhalten heisst, dass alles passieren kann - also steht deine Begruendung "bei mir geht es" auf sehr wackeligen Fuessen und sollte neu ueberdacht werden.
Vielleicht ist jemand lieb genug und schlaegt es im Standard fuer dich nach...
-
bisher hat noch keiner meine aussage widerlegt. Wie kommst du darauf, dass sie falsch ist?
Das stimmt nicht ganz. In der Welt von Standard-C++ ist deine Aussage schlicht weg falsch. Dort ist das Verhalten undefiniert und damit kann es es eindeutig nicht "wahrscheinlich den gleichen effekt" haben.
Verlässt du die Welt des Standards, dann kann man deine Aussage zwar nicht vollständig widerlegen. Ihr Gehalt ist aber für ein technisches Umfeld wie die Programmiererei völlig wertlos.
Hier kommt es doch weniger auf ein globales richtig/falsch sondern mehr auf ein pragmatisches sinnvoll/nicht sinnvoll an.
Insofern machst du hier imo nichts weiter als Haare spalten. Tolle Bechäftigung, bringt einen aber nicht unbedingt weiter.
-
life schrieb:
bisher hat noch keiner meine aussage widerlegt. Wie kommst du darauf, dass sie falsch ist?
Ja, herrje, dann mach ich das eben, mal exemplarisch für mein System:
#include <iostream> struct foo { foo() { std::cout << "foo()\n"; } ~foo() { std::cout << "~foo()\n"; } }; int main() { foo *p = new foo[1]; delete p; }de$ g++ t.cpp && ./a.out foo() ~foo() free(): invalid pointer 0x804a00c!Du kannst jetzt natürlich ankommen und allen erzählen, daß es sonst überall super funktioniert und dir für diese gelungene Argumentation auf die Schulter klopfen, aber es stimmt einfach nicht.
-
Shade Of Mine schrieb:
Vielleicht ist jemand lieb genug und schlaegt es im Standard fuer dich nach...
... um endlich mal für Ruhe zu sorgen.
§5.3.5 Abschnitt 2 sagt:
[...]In the first alternative (delete object), the value of the operand of delete shall be a pointer to a non-array object or a pointer to a sub-object (1.8) representing a base class of such an object (clause 10). If not, the behaviour is undefined. In the second alternative (delete array), the value of the operand of delete shall be the pointer value which resulted from a previous array new-expression ([Fußnote 72] For non-zero-length arrays, this is the same as a pointer to the first element of the array created by that new-expression. Zero-length arrays do not have a first element.) If not, the behaviour is undefined. [Note: this means that the syntax of the delete-expression must match the type of the object allocated by new, not the syntax of the new-expression. ] [...]
-
so grad mal gestestet: Bei mir funktioniert das auch nicht
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.
Aber ich will mich nun mal dazu breitschlagen lassen, dass die aussage wahrscheinlich nicht haltbar ist :>
btw:
Du kannst jetzt natürlich ankommen und allen erzählen, daß es sonst überall super funktioniert und dir für diese gelungene Argumentation auf die Schulter klopfen, aber es stimmt einfach nicht.
wenn sich herausstellt, dass es sonst überall super funktionert, wäre meine aussage selbstverständlich richtig (soweit kannste folgen oder? ;)). Allerdings würde ich mir nicht für die gelungene Argumentation auf die Schulter klopfen, da ich meines wissens garkeine argumente für meine aussage geliefert habe..
-
Hi,
ich glaube da sucht sich jemand Freunde. Bsonders durch den oberlehrerhaften Ton sammelst du hier ne Menge Sympathiepunkte.
-
offensichtlich
-
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
-
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
-
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
-
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.
-
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 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 :>).