T * ptr = new T[1] => delete ptr oder delete[] ptr ??
-
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 :>).
-
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'.
-
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
-
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.
-
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 :>