delete[] und arraylänge
-
hi, woher weiß delete[] wieviel speicher es freigeben muss?
wird das irgendwie intern gespeichert?
wenn ja, dann warum gibt es nicht so eine funktion um die länge eines bestimmten arrays zu bekommen, das per new[] erstellt wurde?
-
wenn nicht, dann woher weiß delete[] wieviel speicher freigegeben werden muss?
-
Delete weiss es einfach. Wie bzw. woher ist AFAIK nicht spezifiziert.
(Und ja, praktisch wird das irgendwo "intern" abgelegt. Der "C" Heap weiss ja z.B. auch wie gross die Blöcke sind die mittels "malloc" angefordert wurden, muss ja bei "free" auch nicht mitgegeben werden - und in C gibts AFAIK ja auch keine Funktion um diese "Blockgrösse" von einem normalen Programm aus abzufragen.)wenn ja, dann warum gibt es nicht so eine funktion um die länge eines bestimmten arrays zu bekommen, das per new[] erstellt wurde?
Wahrscheinlich einfach weil keiner gedacht hat dass es wirklich soviel bringt um die Änderung am Standard zu rechtfertigen. Jede Änderung am Standard ist ein Haufen Aufwand für Compiler Hersteller, und es gibt immer noch keinen C++ Compiler der den Standard 100% implementiert.
-
Theoretisch braucht delete[] die Größe des buffers nichtmal zu wissen, denn delete heisst ja nur, daß der Zeiger auf den Speicher aus der Speicherverwaltung entfernt wird. Dabei wird der Inhalt (abgesehen von speziellen debug-Varianten des new/delete) des Speichers ja weder verändert noch gelöscht. Solange nicht zufällig ein anderes new den gleichen Speicehr wieder belegt bleibt der Inhalt erhalten.
-
jisoa schrieb:
Theoretisch braucht delete[] die Größe des buffers nichtmal zu wissen, denn delete heisst ja nur, daß der Zeiger auf den Speicher aus der Speicherverwaltung entfernt wird. Dabei wird der Inhalt (abgesehen von speziellen debug-Varianten des new/delete) des Speichers ja weder verändert noch gelöscht. Solange nicht zufällig ein anderes new den gleichen Speicehr wieder belegt bleibt der Inhalt erhalten.
Theoretisch muß delete[] die Größe ganz genau wissen, um auch für jedes Objekt den Destruktor aufrufen zu können.
-
Naja ob "delete" das weiss oder nicht, darueber kann man sich streiten ^^
Genaugenommen weiss es aber der speichermanager vom BS, der die allokierten bloecke verwaltet.
Mann kann den speicher mit herkoemmlichen C auch haendich sich vom BS geben lassen, und sogar deren groesse erfragen ... nur ist das nicht mehr teil des standards, weil da jedes BS seinen eigenen Weg hat.Ob c++ z.b. da noch ne schicht zwischenhaengt (stl allokatoren) oder die erfragte adresse wirklich die ist die das BS verwaltet (bei debug code sicher nicht der fall -> speicherguards) das soll alles vom user ferngehalten werden, weil normal braucht man das eigentlich auch nicht, wichtig ist nur das es funktioniert.
Wenn du spezielle anforderungen hasst, also fuellstandsanzeigen vom speicher baun willst, wirst du eigene wege gehen muessen .... (BS fragen wieviel speicher es hat und wieviel es am steuck liefern kann, und den dann selber verwalten)
die new new[] delete delete[] operatoren kann man dann auch ueberladen, das sie eben mit dem eigenen speichermanager arbeiten.
Ciao ...
-
volkard schrieb:
Theoretisch muß delete[] die Größe ganz genau wissen, um auch für jedes Objekt den Destruktor aufrufen zu können.
Das Argument ist ziemlich stark oder? Ich würde das "theoretisch" auch weglassen.
-
Brauch man, unter Windows, überhaupt einen delete[] operator? Windows weiß doch selber intern, dass jetzt 4 mal 4 bytes angefordert wurden. Wo ist da der unterschied zwischen delete und delete[]?
-
bei PODS ist es theorethisch und praktisch wurscht ob du delete oder delete[] nimmst, aber sobald du klassen hasst, bewirkt nur der delete[] operator das von allen deinen elementen im array der dtor aufgerufen wird. beim einfachen delete wird deinen objecten nur der speicher unterm hintern weggezogen ....
deshalb ist es sehr schlechter stil bei einem new[] kein delete[] zu nehmen, egal ob PODs oder ned ....
Ciao ...
-
delete[] nach new oder delete nach new[] ist schlicht und ergreifend nicht definiert. Ob und wo und wann und wieso es trotzdem funktioniert ist uninteressant, wer portabel programmieren will, macht es nach Standard
