Eine Frage zu dynamischen Arrays:

int*array = new int[20];
delete[] array;

bracht delete[] array nicht die Informationen zur Größe von array um diese freigeben zu können?
wenn ja, wo und wie ist die Größe verfügbar?
sollte es dazu nicht eine Standardfunktion geben, memSizeInBytes(array) oder so?

Vielen Dank im Voraus für jede hilfreiche Information!

Statt new benutze vector oder ähnliches. Die merken sich ihre Größe und man kann zudem nichts mehr falsch machen bei der Speicherverwaltung.

ja, das ist ein fehler im design von C++.
dem new sagt man die größe, also sollte man dem delete auch die größe sagen (müssen).

Soll das ein Scherz sein? Es hätte keinen Vorteil, beim Löschen eine Größe angeben zu müssen und wäre bloß eine weitere mögliche Fehlerursache (von denen es bei C++ schon mehr als genug gibt).

Soll das ein Scherz sein? Es hätte keinen Vorteil, beim Löschen eine Größe angeben zu müssen und wäre bloß eine weitere mögliche Fehlerursache (von denen es bei C++ schon mehr als genug gibt).

Du müsstest die Größe ja nicht mit angeben, dass kann der compiler machen, den der kennt bei einem delete die Größe des Objekts. Mit der Information kann man einen allocator effektiver implementieren.

wo weiß der compiler das?

ja, das ist ein fehler im design von C++.

< C++14

http://http://en.cppreference.com/w/cpp/memory/new/operator_delete

void operator delete ( void* ptr, std::size_t sz ); (5) (since C++14)
void operator delete[]( void* ptr, std::size_t sz ); (6) (since C++14)

struct Blk {
    void* ptr;
    size_t size;
}

Blk malloc(int);
void free(Blk);

danke manni66 für den hinweis.

Du müsstest die Größe ja nicht mit angeben, dass kann der compiler machen, den der kennt bei einem delete die Größe des Objekts. Mit der Information kann man einen allocator effektiver implementieren.

Wie wird das begründet? Was ist der Nachteil dabei, die Länge des allozierten Speicherblocks in ptr[-irgendwas] unterzubringen?

Torsten Robitzki schrieb:

Du müsstest die Größe ja nicht mit angeben, dass kann der compiler machen, den der kennt bei einem delete die Größe des Objekts. Mit der Information kann man einen allocator effektiver implementieren.

Wie wird das begründet? Was ist der Nachteil dabei, die Länge des allozierten Speicherblocks in ptr[-irgendwas] unterzubringen?

Du must zur Laufzeit etwas ablegen, was in der Regel zur compiler-zeit bekannt ist. Und Du must etwas mehr Speicher aufwenden, als nötig ist, um die Information abzulegen.

Meist sind Allokatoren so aufgebaut, dass sie für kleinere, Speichergrößen einen eigenen Allocator haben. Aus einem `delete t` könnte also bei zur compilezeit bekanntem sizeof(*t) das direkte Einhängen des Zeigers in eine freelist für diese Länge werden. Das wären dann zwei Zuweisungen.

Ist zu empfehlen.

Andromeda schrieb:

Torsten Robitzki schrieb:

Du müsstest die Größe ja nicht mit angeben, dass kann der compiler machen, den der kennt bei einem delete die Größe des Objekts. Mit der Information kann man einen allocator effektiver implementieren.

Wie wird das begründet? Was ist der Nachteil dabei, die Länge des allozierten Speicherblocks in ptr[-irgendwas] unterzubringen?

Du must zur Laufzeit etwas ablegen, was in der Regel zur compiler-zeit bekannt ist. Und Du must etwas mehr Speicher aufwenden, als nötig ist, um die Information abzulegen.

Okay, aber die Längeninformation zu sparen, halte ich für Mikrooptimierung. Meiner Meinung nach, ist das in den meisten Fällen total sinnfrei. Na ja, aber wer es braucht ...

Torsten Robitzki schrieb:

Meist sind Allokatoren so aufgebaut, dass sie für kleinere, Speichergrößen einen eigenen Allocator haben. Aus einem `delete t` könnte also bei zur compilezeit bekanntem sizeof(*t) das direkte Einhängen des Zeigers in eine freelist für diese Länge werden. Das wären dann zwei Zuweisungen.

Ich sehe es schon kommen: irgendwann hat C++ auch einen schicken, standardmäßigen Garbage Collector.

Okay, aber die Längeninformation zu sparen, halte ich für Mikrooptimierung. Meiner Meinung nach, ist das in den meisten Fällen total sinnfrei. Na ja, aber wer es braucht ...

Naja, wenn Du sehr viele kleine Objekte hast, deren dynamisch alloziierter Speicher nicht viel größer als sizeof(void*) ist, dann fällt das schon ins Gewicht. Entscheidend ist aber, dass wenn die Größe zur Compiler-Zeit bekannt ist, ich evtl. schon einige Schritte bei der Speicherverwaltung sparen kann. Und C++ ist halt um "You pay only for what you use..." (oder so ähnlich) gebaut

Naja, wenn Du sehr viele kleine Objekte hast, deren dynamisch alloziierter Speicher nicht viel größer als sizeof(void*) ist, dann fällt das schon ins Gewicht.

Ja, durchaus.

Torsten Robitzki schrieb:

Entscheidend ist aber, dass wenn die Größe zur Compiler-Zeit bekannt ist, ich evtl. schon einige Schritte bei der Speicherverwaltung sparen kann.

Da kann ich dir jetzt nicht ganz folgen. Dass der Allokator die Größe nur intern kennt und man sie nicht abfragen kann, halte ich auch für eine Design Schwäche. Mit dem Vorschlag von Alexandrescu kann ich auch durchaus was anfangen. Da wird die Größe aber auch zur Laufzeit mitverwaltet. Aber wie willst du das einsparen und nur vom Compiler erledigen lassen, wenn du im Programm Zeiger rumreichst, die nicht die Größeninformationen mitschleppen?

Aber wie willst du das einsparen und nur vom Compiler erledigen lassen, wenn du im Programm Zeiger rumreichst, die nicht die Größeninformationen mitschleppen?

Wenn wir vom nicht array-Fall ausgehen, dann steckt die Größeninformation im Typen für den Fall dass der statische Typ dem dynamischen Typ entspricht (also kein delete über einen Zeiger auf eine Basis mit virtuellem Destruktor).

Für arrays muss die Größe des Arrays zur Laufzeit mit abgelegt werden, weil sich die nicht aus dem Typen ableiten lässt.

Da haben wir wohl etwas aneinander vorbei geredet, sorry.

Typen wie std::vector<>, die wahrscheinlich die Hauptnutzer von dynamisch alloziierten arrays sind, kennen die Größe des alloziierten Speichers sogar nochmal explizit, sodass der allocator die Information an der Stelle auch nicht mehr braucht.

Naja, wenn Du sehr viele kleine Objekte hast, deren dynamisch alloziierter Speicher nicht viel größer als sizeof(void*) ist, dann fällt das schon ins Gewicht.

Sicherlich; je höher die Frequenz von new/delete, desto störender macht sich jeder einzelne Taktzyklus dieser Funktionen bemerkbar. Wer aber auf solche Probleme stößt, der sollte vielleicht bessser mal seinen Programmierstil überprüfen, als auf die Heap-Verwaltung zu schimpfen.

Torsten Robitzki schrieb:

Entscheidend ist aber, dass wenn die Größe zur Compiler-Zeit bekannt ist, ich evtl. schon einige Schritte bei der Speicherverwaltung sparen kann.

Ja, klar. Ein schlauer Compiler wird womöglich für sowas gar nicht erst den Heap benutzen, sondern solche kurzlebigen Miniobjekte im Stackframe speichern, falls sie funktionslokal bleiben, oder gar eine eigene Speicherverwaltung dafür mitbringen.

ja, das ist ein fehler im design von C++.
dem new sagt man die größe, also sollte man dem delete auch die größe sagen (müssen).

Was ist dein Argument dafür? Symmetrie? Kann ich nicht durchgehen lassen, ist beim Programmieren oft einfach keine gute Idee alles auf Teufel-komm-raus symmetrischen machen zu wollen.
Mal ganz davon abgesehen dass oft nicht klar ist was "symmetrisch" überhaupt bedeuten soll.

Man könnte genau so sagen symmetrisch wäre es, wenn man bei new die Grösse angibt und nen Zeiger zurückbekommt, und bei delete den Zeiger angibt und die Grösse zurück bekommt. Wäre aber genau so beknackt (noch beknackter).

Und...
Wenn es deiner Meinung gut/korrekt/... wäre dass man bei delete die Grösse mitgeben muss...
Was ist dann mit fclose()? Sollte man da den Filenamen nochmal angeben müssen? -> Blödsinn.
Bzw. mit jedem Destruktor eines Objekts dessen Konstruktor man mit bestimmten Parametern aufgerufen hat?

Nene.
Der Designfehler ist höchstens dass man die Grösse nicht abfragen kann. Weil die Implementierung sich die Grösse sowieso merken muss (zumindest bei Arrays aus Objekten mit nicht-trivialem Dtor).

Nene.
Der Designfehler ist höchstens dass man die Grösse nicht abfragen kann.

Das kannst du doch spielend leicht umgehen, indem du sie selber speicherst.
Jetzt wird es aber albern.

Jodocus schrieb:

Es ist mehr noch ein Fehler von C gewesen, wie Alexandrescu angemerkt hat:

struct Blk {
    void* ptr;
    size_t size;
}

Blk malloc(int);
void free(Blk);

Machst du eigentlich noch was anderes als mit aus Prinzip zu "kritisieren", egal wie sinnvoll oder sinnlos die "Kritik" fachlich ist?

Dann wäre es wieder relativ sinnlos auf die Größe zugreifen zu können, weil man sich ja nicht darauf verlassen kann dass diese auch der Größe des arrays entspricht.

Aber ist es nicht so dass die tatsächlich allozierte Größe eh Implmentierungsabhängig ist (also dass auch mehr Speicher reserviert werden kann als angefordert)?

Ja, klar. Üblicherweise ist der zurückgebene Pointer Teil eines ListElements des Allokators und außerdem kann es durchaus sein, dass deine angefordete Speichergröße aufgerundet wird, weil der Allokator eine bestimmte Granularität voraussetzt, um Fragmentierung zu minimieren.

happystudent schrieb:

Dann wäre es wieder relativ sinnlos auf die Größe zugreifen zu können, weil man sich ja nicht darauf verlassen kann dass diese auch der Größe des arrays entspricht.

Nicht zwangsläufig, weil der Allokator das ja verrechnen kann. Zugegeben: das ist wieder ein Sonderfall, wie das vielzitierte hochfrequente allozieren und freigeben kleiner Objekte. Aber manche lieben sowas ja.

Aber manche lieben sowas ja.

Das glaube ich nicht. Es gibt welche, die haben keine Ahnung von sowas und deswegen ist es denen egal (aber sie bevorzugen dann diesen Stil, ja). Aber es gibt auch viele Fälle, da kommst nicht drumherum. Allein schon type erasure wie bei std::function oder tausende andere Fälle, wo man das einfach braucht oder die Alternativen andere Nachteile haben.

ps: Es gibt nämlich Allokatoren die Pools für kleine Allokationen verwenden, wo mehr als nur ein wenig aufgerundet werden muss. Also angenommen 160 Byte werden für 10 Objekte a 16 Byte angefordert, aber der kleinste passende Pool verwaltet 180 Byte Blöcke. Das wären dann 11 Objekte wenn man zurückrechnet. Bei Arrays aus Objekten mit trivialem Destruktor wäre das egal, es muss ja nur der Speicher freigegeben werden. Und das kann der Allokator, ohne dass er sich irgendwo pro Block merkt wie gross dieser war, so lange der Block aus einem seiner fixgrösse Pools stammt. (Man kann das so implementieren dass man anhand der Adresse feststellen kann aus welchem Pool ein Block kommt. Und damit kennt man dann die Grösse des Pool-Blocks, also die 180 Byte. Nicht aber die 160.)

Wenn der Destruktor aber aufgerufen werden muss, dann muss die Implementierung halt doch wissen dass es bloss 10 Objekte sind.
D.h. wenn die Implementierung nicht an einen Allokator gebunden ist (=mit beliebigen Allokatoren klar kommen will/muss), dann muss sie - egal was der Allokator macht - die Grösse in diesem non-trivial-dtor Fall selbst nochmal irgendwo abspeichern.

Im Worst Case wären wird dann bei drei Kopien der Grösse:
1x im bzw. für den Allokator selbst
1x irgendwo für die C++ Implementierung
1x im eigenen Programm

Sogesehen halte ich es schon für eine "ungünstige" Entscheidung dass man die Array-Grösse grundsätzlich nicht abfragen kann. Grundsätzlich immer wäre vermutlich auch verkehrt, weil man dadurch bei Allokatoren wie oben beschrieben und trivial-dtor Objekten wieder eine u.U. unnötige Kopie der Grösse erzwingen würde.