Der Aufruf von delete auf den Variablen auf dem Stapel reserviert

Ignorieren Programmierung Stil und design, ist es "sicher" zu nennen, delete auf eine variable auf dem Stapel reserviert?

Beispiel:

   int nAmount;
   delete &nAmount;

oder

class sample
{
public:
    sample();
    ~sample() { delete &nAmount;}
    int nAmount;
}
Warum würden Sie wollen?
Verwandte: stackoverflow.com/questions/434140/...
In etwa so sicher ist wie stochern einen scharfen Nadel in Ihrem Auge.
Nasen-Dämonen - dies ist, was passiert
Ein Kätzchen getötet wird, irgendwo.

InformationsquelleAutor unistudent | 2009-01-14

  1. 96

    Keine, es ist nicht sicher, rufen Sie delete auf eine stack-variable zugewiesen. Sie sollten nur anrufen delete auf Dinge, die erstellt von new.

    • Für jeden malloc oder calloc, es sollte genau einen free.
    • Für jeden new es sollte genau einen delete.
    • Für jeden new[] es sollte genau einen delete[].
    • Für jede stack-allocation, sollte es keine explizite freigeben oder löschen. Der Destruktor wird automatisch aufgerufen, falls zutreffend.

    Im Allgemeinen, Sie können mix and match diese z.B. keine free-ing oder delete[]-ing eine new Objekt. Dies führt zu undefiniertem Verhalten.

    Danke! Mein compiler nicht seg Schuld, aber ich war auf jeden Fall misstrauisch, wenn es legitim.
    In Ihren Bearbeitungen, können wir ersetzen jedes "sollen" mit "müssen".
    "Sollte" ist ein besseres Wort. "Müssen" impliziert, dass ein malloc/new/new[] wird scheitern, wenn die free/delete/delete[] nicht vorhanden ist, was nicht der Fall ist. Die Verwendung von "genau eins" trägt die Implikation, die ich denke, Sie werden für.
    Vielen Dank, Sie sind richtig. Behoben.

    InformationsquelleAutor Mr Fooz

  2. 46

    Gut, versuchen wir es:

    jeremy@jeremy-desktop:~$ echo 'main() { int a; delete &a; }' > test.cpp
jeremy@jeremy-desktop:~$ g++ -o test test.cpp
jeremy@jeremy-desktop:~$ ./test
Segmentation fault

    Also anscheinend ist es überhaupt nicht sicher.

    Ich weiß, das ist eine alte Antwort, aber ich fühle mich gezwungen, zu kommentieren, versuchen, etwas, das möglicherweise nicht der beste Weg, um zu beweisen, dass es sicher ist; wenn es funktionierte, würde das nicht bedeuten, dass der Betrieb sicher ist oder dass das Verhalten ist klar definiert, es würde nur beweisen, dass es funktioniert einmal. (Können Sie beweisen auf diese Weise, dass Dinge, die funktioniert nicht, aber das umgekehrte nicht immer halten.)
    Dies ist ein irrelveant Bemerkung. Sie versuchen etwas und finden, dass es unsicher ist nicht beweisen, dass es unsicher ist. Dies ist, was die Antwort ist. Wenn der Beantworter nicht hatte, fand sein Beispiel, segfault, er hätte einfach nicht gepostet. Sie weiß nicht, wie viele Dinge, die er versucht, vor erreichen, dass Beispiel.
    Ich glaube nicht, dass Sie bekam cdhowies Punkt. Es gibt viele Dinge in C++, die nicht sicher, aber kann zu arbeiten. Ich bin sicher, Sie finden einen compiler produziert code, der nicht segmentation Fault, weil Sie dachte, es wäre ein großartiges feature. Alles funktioniert einfach toll. Wechseln Sie nun compiler und beachten Sie, dass, nur weil Sie nicht erhalten eine Fehlermeldung, die mit der vorherigen compiler bedeutet nicht, dass Ihr code ist nicht schlecht und unfähig zu arbeiten, mit anderen compiler. Informatik ist komplexer, als es 'klappte Es dieses mal, so muss es vollkommen in Ordnung ist.' Auch nicht zu erwähnen, das Konzept der "Undefiniertes Verhalten"
    Ich glaube, du verpasst meine Punkt @itzJanuary
    Um fair zu sein, ich glaube, ich habe.

    InformationsquelleAutor Jeremy Ruten

  3. 14

    Beachten Sie, dass beim reservieren eines Speicherblocks mit neuen (oder malloc für diese Angelegenheit), die tatsächliche blockieren des Arbeitsspeichers größer sein wird als das, was Sie gefragt haben.
    Der Speicherblock enthält auch einige historische Angaben, so dass, wenn Sie sich frei den block, kann es leicht sein, wieder in den freien pool und vielleicht sein verschmolzen mit den angrenzenden frei-Blöcke.

    Wenn Sie versuchen, um Speicher frei, dass Sie didn ' T erhalten neue, dass die Buchführung Informationen nicht da sein, aber das system wird handeln, wie es ist, und die Ergebnisse werden unberechenbar (in der Regel schlecht).

    InformationsquelleAutor Ferruccio

  4. 10

    Ja, es ist Undefiniertes Verhalten: vorbei an delete alles, was nicht von new ist UB:

    C++ - standard, Abschnitt 3.7.3.2.3:
    Der Wert für das erste argument geliefert, um eine thea-Freigabe-Funktionen in der standard-Bibliothek kann ein null - Zeiger-Wert; wenn dem so ist, und wenn die Freigabe-Funktion ist eine Lieferung in der standard Bibliothek, der Aufruf der Freigabe-Funktion hat keine Auswirkungen. Andernfalls wird der Wert geliefert operator delete(void*) in der standard-Bibliothek ist einer der Werte, die von einem früheren Aufruf von entweder operator new(std::size_t) oder operator new(std::size_t, const std::nothrow_t&) in der standard-Bibliothek.

    Den Folgen des undefinierten Verhalten sind, naja, nicht definiert. "Nichts passiert" ist genauso gültig, eine Folge, als alles andere. Es ist jedoch in der Regel "nichts geschieht sofort": die Freilassung eines ungültigen Speicherblock kann schwerwiegende Folgen haben, die in nachfolgenden aufrufen der Zuweisung.

    InformationsquelleAutor dasblinkenlight

  5. 7

    Nach dem spielen ein bisschen mit g++ 4.4 in windows, bekam ich sehr interessante Ergebnisse:

    1. Aufruf von delete auf eine stack-variable scheint nicht, etwas zu tun. Keine Fehler werfen, aber ich kann auf die variable ohne Probleme nach dem löschen.

    2. Dass eine Klasse mit einer Methode mit delete this erfolgreich löscht das Objekt, wenn es zugeordnet ist, in den Haufen, aber nicht, wenn es zugeordnet ist, in dem Stapel (wenn es in dem stack, passiert nichts).

    Deine Antwort ist tatsächlich relevant für die Frage. Es sind immer zu viele evangelist Programmierer auf SO verurteilen niemanden, der fragt, eine Frage aus der eigenen reiner Neugier (der Grund, warum ich hier bin), was der standard ist, sollte das auftreten in unerwarteten Ecke Fällen einer Sprache.
    1. ist wahrscheinlich nicht definiertes Verhalten..

    InformationsquelleAutor Sambatyon

  6. 5

    Niemand kann wissen, was passiert. Dies ruft nicht definiertes Verhalten, also buchstäblich alles passieren kann. Dies nicht tun.

    OK, vermutlich habe ich einen Hierarchie-Baum der parent/child-Objekte. Der Baum ist verantwortlich für rekursiv aufrufen verschiedene Objekt-Methoden und beim löschen eines root-Objekt alle Kinder rekursiv gelöscht. Aber einige der Kinder können Umfang zugeteilt, andere dynamisch, in diesem Fall ist es nicht möglich, zwischen beiden zu unterscheiden und nur löschen dynamische Objekte ohne hinzufügen von ein paar mehr Daten angeben?
    Nein, es ist nicht möglich, dass die Informationen nur einem Zeiger. Könnten Sie std::shared_ptr mit einer custom deleter, die nichts tut, um nicht-dynamische Objekte, oder Ihre eigenen Metadaten hinzufügen, oder kommen mit einer weniger gewundenen lifetime-management-Strategie.
    Normalerweise gehe ich durch eine einfache Regel: das Objekt oder Den Bereich, ist verantwortlich für die Objekt-Erstellung ist auch verantwortlich für seine Löschung. Oder anders: nicht delete ein Objekt, das Sie noch nicht newed in den ersten Platz.
    wenn Sie dies benötigen, Ihr design ist ernsthaft fehlerhaft. Überdenken Sie, sollte dies kein problem sein.
    Wo hast du die QObject-Zeug aus? In der Qt-API-docs, bei QObject::~QObject(), es sagt ganz klar: Warnung: Alle untergeordneten Objekte gelöscht. Wenn eines dieser Objekte auf dem stack oder global, früher oder später wird Ihr Programm Abstürzen.

    InformationsquelleAutor

  7. 4

    Nein,
    Speicher mit new gelöscht werden sollen, mithilfe von delete-operator
    und, die zugeordnet mit malloc sollten gelöscht werden frei.
    Und keine Notwendigkeit zum freigeben der variable, die zugeordnet sind, auf Stapel.

    InformationsquelleAutor Vinay

  8. 3

    Ein Engel verliert seine Flügel... man kann Sie nur anrufen delete auf einem Zeiger zugewiesen mit new, ansonsten bekommst du Undefiniertes Verhalten.

    InformationsquelleAutor Luchian Grigore

  9. 1

    hier der Arbeitsspeicher ist mit stack, so dass keine Notwendigkeit, es zu löschen exernally aber wenn Sie allcoted dynamisch

    wie
    int *a=new int()

    dann muss man löschen und nicht löschen &a(a selbst ist ein Zeiger), weil der Arbeitsspeicher ist von free-Shop.

    InformationsquelleAutor

  10. 0

    Du die Frage bereits beantwortet sich selbst. delete darf nur verwendet werden für Zeiger eingeholt durch new. Etwas anderes zu tun, ist schlicht und einfach ein Undefiniertes Verhalten.

    Daher ist es wirklich nicht sagen, was passiert, etwas von der code funktioniert Prima durch Absturz zu löschen Ihrer Festplatte ist ein gültiges Ergebnis, dies zu tun. Also bitte dies nie tun.

    InformationsquelleAutor Grizzly

  11. 0

    Es ist UB, da müssen Sie nicht rufen Sie löschen auf ein Element, das nicht dynamisch zugewiesen, mit neuen. So einfach ist das.

    InformationsquelleAutor Martin James

Schreibe einen Kommentar