delete[]
-
Original erstellt von DragonMaster:
weil eine Speicheranforderung an das Betriebsystem geht, und nicht dem new-Operator überlassen wird.Falsch. Das mag bei einzelnen Implementationen so sein, schließlich macht der Standard keine Aussage darüber. Aber bei den Betriebssystemen die ich kenne würde das nicht funktionieren (DOS, Unix). Die Runtime benutzt natürlich die OS-Funktionen, um mehr Speicher zu bekommen. Aber in einer anderen Granularität als du new anwendest. Das ist wie mit dem std::vector ... ein einzelnes push_back führt idR nicht zur Neuallokation, das passiert erst, wenn eine bestimmte Schwelle überschritten wird.
-
@Volkard
Ok. Hatte deinen Satz falsch verstanden. Dachte du meintest der Allokator würde zusätzlich zum Container noch die Größe speichern.Auf der anderen Seite finde ich deinen Einwand etwas merkwürdig. Schließlich gibt es keine portable Möglichkeit an die durch den op new erzeugte Information zu kommen.
Das ist zwar schade, aber solange es die Realität ist, sehe ich irgendwie nicht wie man um das Speichern der Größe drum rum kommt.
-
Original erstellt von HumeSikkins:
Auf der anderen Seite finde ich deinen Einwand etwas merkwürdig. Schließlich gibt es keine portable Möglichkeit an die durch den op new erzeugte Information zu kommen.
Das ist zwar schade, aber solange es die Realität ist, sehe ich irgendwie nicht wie man um das Speichern der Größe drum rum kommt.Ja, es ist schade. Man hat ein ungutes Gefühl dabei, daß man nicht ran darf. Es wäre doch so fein, wenn man dürfte. usw.
Und natürlich ist es legitim, zu fragen: "wie kommt man denn da ran?".
Wir wissen ja, daß es keinen portablen Weg gibt.
Aber da schrieb einer "Sowie sich Dir jenes Problem stellt, stimmt was mit Deinem Layout nicht."
Und das hielt ich für ein wenig gar oberdreist. Also schrieb ich ihm, daß er nen knall hat, wenn er nichtmal das legitime anliegen sieht.ich wünschte mir auch machmal, daß es einen legitimen weg gäbe.
-
wenn man die groesse will ist eine
template <class Type>
class YAarray{
private:
T *varray;
int size;
public:
// konstruct init access destuct hier//
};mit weniger aufwand zu haben
wenn man das globale ueberwachungs Konzept nutzen wuerde muesste man ja suchen und da is die eine variable mehr nich schlimm.
-
Das Problem warums nicht geht (hat mir mal einer von Euch hier erklärt) ist doch, dass es sein kann, dass new z.B. einen größeren Block belegt, als man anfordert, weils schneller sein kann immer 32-Bit-Blöcke o.ä. zu reservieren.
Und das ist natürlich System- und Implementierungsabhängig.Der Wert, der für das delete[] also irgendwo gespeichert wird ist also >= dem angeforderten und würde einem in den meisten Fällen nicht weiterhelfen. Der angeforderte wird hingegen nirgens gespeichert, weswegen man ihn extra speichern muss -> das ist keine redundante Datenhaltung
Hat man allerdings ein dynamisch wachsendes Array, wärs aber vielleicht gerade nützlich den tatsächlich reservieren Speicher zu kennen.
-
und wieso wird dann immer die richtige Zahl von destruktoraufrufen aufgerufen?
-
hm, das ist ne gute Frage, wegen welcher ich Euch bitten muss meinen obigen Beitrag als nie geschrieben zu betrachen :o
-
klaro
-
Original erstellt von <hhh>:
und wieso wird dann immer die richtige Zahl von destruktoraufrufen aufgerufen?aber bei buildins und PODs könnte man trozdem den schnelleren block allocier modus benutzen
alles unter einen hut bringen könnte man das so
foo * f = new foo[20]; pod * p = new(block_alloc) pod[100]; size_of_alloc( f ); // 20 size_of_alloc( p ); // in der docu zu size_of_alloc würde dann stehen // das wenn man den block mit den block_alloc new geholt hat // das ergebnis (die zahl, nicht der aufruf) undefiniert ist
-
Original erstellt von Dimah:
**aber bei buildins und PODs könnte man trozdem den schnelleren block allocier modus benutzen
**hab ich auch nie was gegen gesagt
