Ist delete[] gleich löschen?

IP_ADAPTER_INFO *ptr=new IP_ADAPTER_INFO[100];

wenn ich kostenlos mit

delete ptr;

wird es zu Speicherverlust führen, wenn nicht, dann warum ?

Dies ist disassembly-code generiert VS2005

; delete ptr;
0041351D  mov         eax,dword ptr [ptr] 
00413520  mov         dword ptr [ebp-0ECh],eax 
00413526  mov         ecx,dword ptr [ebp-0ECh] 
0041352C  push        ecx  
0041352D  call        operator delete (4111DBh) 
00413532  add         esp,4 

; delete []ptr;
00413535  mov         eax,dword ptr [ptr] 
00413538  mov         dword ptr [ebp-0E0h],eax 
0041353E  mov         ecx,dword ptr [ebp-0E0h] 
00413544  push        ecx  
00413545  call        operator delete[] (4111E5h) 
0041354A  add         esp,4

Was haben die docs gesagt?
ich habe gelesen , dass der Destruktor aufgerufen wird, werden für das erste element im array, sondern ganze Speicher wird freigegeben, gleiche ich sehe beim Debuggen
Nein, nur das erste element wird freigegeben, andere nicht.
Nein, das ist nicht sicher. Kann es passieren, dass Weg, aber dann ist es vielleicht nicht. Für Hülsen, es ist sogar wahrscheinlich, dass es vielleicht nicht. Aber man weiß ja nie.
Was wird passieren, wenn IP_ADAPTER_INFO aufhört zu POD-Typ? Wollen Sie Bearbeiten den code? Sie versehen Ihre Frage mit C++ tag, so sollten Sie überlegen, mit std::vector.
Ich empfehle das ignorieren dieser Frage und statt zu Lesen [delete vs delete[]](stackoverflow.com/questions/4255598/delete-vs-delete) statt, deren Antworten sind viel mehr auf den Punkt.

InformationsquelleAutor Satbir | 2009-10-12

c++memory-management pod

146

Ob dies führt zu einem Speicherverlust, wischt Ihrer Festplatte, wird Sie Schwanger, macht fiesen Nasen-Dämonen, die Sie jagen rund um Ihre Wohnung, oder lässt alles funktionieren ohne erkennbare Probleme, ist nicht definiert. Könnte es so sein mit einem compiler, und ändern Sie mit einem anderen, ändern sich mit einer neuen compiler-version, mit jeder neuen Zusammenstellung, mit den Mond-Phasen, Ihrer Stimmung, oder je nach der Anzahl der neutrinos, die durch die übergebene Prozessor auf dem letzten, sonnigen Nachmittag. Oder ist es vielleicht nicht.

All das und unendlich viele andere Möglichkeiten sind in einem Begriff: Undefiniertes Verhalten:

Nur bleiben Weg von es.
- Ich würde sagen, dass "Undefined behavior" ist "schlecht" und sollte vermieden werden, wie Sie sagen. Das bedeutet aber auch, dass in einigen Fällen ist es tatsächlich ein Speicherleck, und Sie sollten Immer code, so dass Sie lösen worst-case-Szenarien. Das ist meiner Meinung nach sowieso.
- vorausgesetzt, Ihr eigenes Programm ruft ein Undefiniertes Verhalten? ist, dass einige entwickelte form der defensiven Programmierung?
- +1 für eine korrekte. Reden, wie delete und delete[] verhält sich in einigen spezifischen Implementierung gibt nur die falsche Idee. Es ist Undefiniertes Verhalten: tun Sie es nicht.
InformationsquelleAutor sbi

Nur eine Darstellung von etwas "Undefiniertes" Verhalten auf bestimmte Betriebssysteme und Compiler. Hoffe, es könnte hilfreich sein für die Menschen, um Ihren code Debuggen.

Test 1

#include <iostream>
using namespace std;
int main()
{
  int *p = new int[5];
  cout << "pass" << endl;
  delete p;
  return 0;
}

Test 2

#include <iostream>
using namespace std;
int main()
{
  int *p = new int;
  cout << "pass" << endl;
  delete[] p;
  return 0;
}

Test 3

#include <iostream>
using namespace std;
struct C {
  C() { cout << "construct" << endl; }
  ~C() { cout << "destroy" << endl; }
};

int main()
{
  C *p = new C[5];
  cout << "pass" << endl;
  delete p;
  return 0;
}

Test 4

#include <iostream>
using namespace std;
struct C {
  C() { cout << "construct" << endl; }
  ~C() { cout << "destroy" << endl; }
};

int main()
{
  C *p = new C;
  cout << "pass" << endl;
  delete[] p;
  return 0;
}

Windows 7 x86 msvc 2010. Kompilieren mit Standard-Optionen, d.h. die exception-handler aktiviert ist.

Test 1

pass

Test 2

pass

Test 3

construct
construct
construct
construct
construct
pass
destroy
# Then, pop up crash msg

Test 4

construct
pass
destroy
destroy
destroy
destroy
destroy
destroy
destroy
... # It never stop until CTRL+C

Mac OS X 10.8.5, llvm-gcc-4.2 oder gcc-4.8 erzeugen die gleiche Ausgabe

Test 1

pass

Test 2

pass

Test 3

construct
construct
construct
construct
construct
pass
destroy
a.out(71111) malloc: *** error for object 0x7f99c94000e8: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
zsh: abort      ./a.out

Test 4

construct
pass
a.out(71035) malloc: *** error for object 0x7f83c14000d8: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
zsh: abort      ./a.out

Ubuntu 12.04 AMD64, gcc 4.7

Test 1

pass

Test 2

pass

Test 3

construct
construct
construct
construct
construct
*** glibc detected *** ./a.out: munmap_chunk(): invalid pointer: 0x0000000001f10018 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fe81d878b96]
./a.out[0x400a5b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fe81d81b76d]
./a.out[0x4008d9]
======= Memory map: ========
....
zsh: abort (core dumped)  ./a.out

Test 4

construct
destroy
destroy
destroy
destroy
destroy
destroy
destroy
destroy
...
destroy
destroy
*** glibc detected *** ./a.out: free(): invalid pointer: 0x00000000016f6008 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fa9001fab96]
./a.out[0x400a18]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fa90019d76d]
./a.out[0x4008d9]
======= Memory map: ========
...
zsh: abort (core dumped)  ./a.out

Dein test noch nicht nachweisen, ob es memory leaks.

InformationsquelleAutor jichi

7

Wird es in der Regel nicht Auslaufen, weil im Fall von POD-Destruktoren sind trivial und es gibt keine Notwendigkeit für den Aufruf des von Ihnen so delete nur freigibt belegte Speicher durch das array. Memory-deallocation-benötigt nur einen Zeiger-Wert, so wird es zurück auf den Haufen. Das array accopies einen zusammenhängenden block von Speicher und damit die Freigabe kann erfolgreich nur als wenn es eine Freigabe von einem einzigen element.

Aber verlassen Sie sich nicht auf dieses, da es ist Undefiniertes Verhalten. Vielleicht funktioniert es in Ordnung, vielleicht etwas schreckliches passiert, arbeiten am compiler, nicht am anderen, und viele Menschen danken Ihnen für das Einpflanzen einen Fehler.

Sehen diese Antwort für details.
- Warum war das downvoted ich Frage mich...
- Da new T[] können hinzufügen, ein sizeof offset-unabhängig von der POD-ness von T, in welchem Fall delete[] wird dies kompensieren. delete würde der header-block Zuweisung von ein paar bytes, die Interpretation einer (möglicherweise nicht initialisierten) element Anzahl als header und verursachen unvorhersehbare heap-Beschädigung. Was natürlich zeigt sich erst, wenn der boss das sieht.
- Sicher, das ist, warum das Wort meistens ist es. Und heap-Beschädigung ist kein Leck.
- struct A { void operator delete[](void *p, size_t t) { } }; obwohl struct A ist ein POD, new A[10] ordnen und zu speichern, die Größe und die delete[] haben, um es abzurufen und es passieren Betreiber löschen
InformationsquelleAutor sharptooth
4

löschen :
ruft die entsprechende Destruktor nur für das element hingewiesen (falls erforderlich),
dann gibt den Speicher chunk

delete[] :
ruft die entsprechende Destruktor für jedes element in seiner Reihe (falls erforderlich),
dann gibt den Speicher chunk
- Dies alles wahr ist nur wenn delete und delete[] korrekt verwendet werden. Diese Frage ist insbesondere etwa der Fall, wenn delete wird dort verwendet, wo delete[] hätte.
InformationsquelleAutor FranckSpike
3

Wenn Einem Punkte für ein array reserviert wurde über new T[n], dann müssen Sie es löschen per delete[] A.

Warum?

Den Unterschied zwischen delete und delete[] ist einfach - der ehemalige zerstört ein Skalar-Objekt und die letztere zerstört ein array.

Mehr info hier und hier.

UPDATE 1 (falsch):

Wenn Sie mit delete (und nicht mit delete []), während die Zuweisung mit new T[n], nur das erste element wird freigegeben, während andere nicht sind destructorized, das führt zu Speicherverlust. Warum? Dies ist der Weg, Bjarne Stroustrup, und andere entworfen hatte, die Sprache. Und es ist nicht compiler-Variation. Wenn ein compiler plant den anderen Weg, es ist nur nicht nach dem standard. Die Programmiersprache C++ , Kapitel 6.2.6.2 und 19.4.5.

UPDATE 2 (richtig):

Ich bin zuzugeben, mein Fehler, über das Verhalten der Verwendung der delete-operator für Allokationen mit new T[n]. Lesen Sie das erwähnte Dokument finde ich nicht die genaue Beschreibung, so dass ich vermute, in dieser situation das Verhalten wird undefined und variiert von compiler zu compiler. AFAIK, MSVC-compiler zum Beispiel erzeugt anderen code als der GCC. Bitte ignorieren Sie UPDATE 1.
- Niemand (auch nicht Bjarne, geschweige denn einige Bjorn) angegeben, dass nur ein Objekt freigegeben werden. Es ist undefined. (Und, wie gesagt, anderswo, die ich gearbeitet habe, mit mindestens einem compiler, der befreit Sie alle.)
- Ich denke mal du meinst Bjarne, nicht Björn?
- Behoben. Sorry, Bjarne 🙂
- sbi, die das Verhalten für bestimmte compiler kann werden nicht definiert. Aber, wie gesagt, dieser compiler wird nicht nach der C++ - standard. Check research.att.com/~bs. Es gibt einige erwähnt, die für diese spezielle Frage.
- mit diesem compiler - ich sehe nicht ein Verweis auf einen bestimmten compiler (mehr) ? "Undefiniertes Verhalten" ist eine ISO-Standard-Begriff, und bezieht sich nicht auf irgendeine bestimmte Implementierung.
- Ich wiederhole, diese speziellen Verhalten ist definiert durch einen standard.
- Der C++ - standard besagt ausdrücklich (zumindest in der it-draft-version vom 13.9.2001, die ich zur hand haben), dass ein solches Verhalten ist nicht definiert: In der ersten alternative (Objekt löschen), wird der Wert des Operanden von delete wird ein Zeiger auf eine nicht-array-Objekt oder ein Zeiger auf ein sub-Objekt (1.8), die einen Basis-Klasse von der ein Objekt (Ziffer 10). Wenn nicht, ist das Verhalten undefiniert. In der zweiten alternative (array löschen), wird der Wert des Operanden von delete wird der Zeiger-Wert, der resultiert aus einem früheren array-new-Ausdruck.72) Wenn nicht, ist das Verhalten undefiniert.
- Kapitel und vers bitte.
- Die C++ - Programmiersprache 6.2.6.2, 19.4.5
- Weder von diesen existiert in meiner Kopie (C++98). Sowieso, der standard gibt nur an, was Sie sagte, bevor Sie die updates: Man zerstört eine Skalare Objekt, das andere zerstört ein array. Es hat nicht sagen, was du in deinem ersten update, dass, wenn die Skalare löschen aufgerufen wird ein array, das erste Objekt zerstört wird. Das ist nicht garantiert der standard. Es ist einfach nicht definiert.
- Ich hätte von Ihnen positiv bewertet werden, aber nach der Lektüre von "Update", ich lieber nicht 🙁
- Dank jalf, sbi, Komat. Sie wo Recht ist, würde ich gestand meine Fehler und aktualisiert die post.
- Bitte aktualisieren Sie Ihren Beitrag so, dass alle diese widersprüchliche updates Weg sind / oder die richtigen Informationen, ist auf der Oberseite
InformationsquelleAutor Andrejs Cainikovs
-4

Array von POD es wird nicht Leck (mit den meisten Compilern). Zum Beispiel, MSVC generiert identisch code für löschen und delete[] für array POD.

Persönlich, ich denke, dass C/C++ könnte ohne operator delete[]. Compiler kennt die Größe des Objekts und den zugeordneten Speicher-Größe ist zur Laufzeit bekannt, so ist es sehr einfach zu wissen, ist ein Zeiger-array ist oder nicht und entsorgen Sie den Speicher in einem richtigen Weg.

EDIT:

OK, Jungs. Können Sie test in Ihre compiler-und sagen, ob es ein Leck?

Versuchen zu denken, da ein compiler-Entwickler. Wir haben neue, new[], löschen, delete[]. Jeder neue hat seine eigene löschen. Scheint perfekt und vollständig. Mal sehen, was passiert, wenn Sie anrufen delete[]?
```
1. call vector destructor for an object
2. actual free memory
```
Was ist ein Destruktor für POD? Nichts!
Also, Aufruf löschen für array POD wird nicht undicht!!! Auch wenn es Pausen der standard. Auch wenn es nicht empfohlen wird.

EDIT2:

Dies ist disassembly-code generiert von VS2008:
```
operator delete[]:
78583BC3  mov         edi,edi 
78583BC5  push        ebp  
78583BC6  mov         ebp,esp 
78583BC8  pop         ebp  
78583BC9  jmp         operator delete (78583BA3h) 
```
- delete[] ist definitiv nicht eine form der Optimierung. Es geht um Richtigkeit.
- Ja, aber ist ist überflüssig. Die Menschen wollen wissen, ob es undicht wird und ich antwortete. Warum downvote?
- Durch die Art und Weise, wie ich RICHTIGKEIT. Aber wir diskutieren es nicht...
- Ich kann nicht sprechen für die anderen, aber ich nach unten gestimmt, weil Sie gesagt "Für array-POD wird es nicht Auslaufen" - auch wenn Sie etwas gespielt, diese später. Was dies bedeutet ist undefined. Zeitraum. (Es bestehen begründete Annahmen, aus denen man ableiten kann, mögliche Szenarien, aber Sie definitiv passt nicht allen Compilern oder auch compiler-Versionen, so dass diese Aussage scheint mir falsch zu sein.)
- Gut, sagte ich "(mit den meisten Compilern)". Aber trotzdem danke! Ich werde vorsichtiger sein in meiner Aussage.
InformationsquelleAutor Sergey Podobry

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.