T
HansKlaus schrieb:
welchen overhead? irgendwo muss doch sowieso gespeichert werden, wie groß das array ist, weil das betriebssystem sonst gar nicht weiß, wie viel speicher es noch zur verfügung hat.
Das Betriebssystem hat in der Regel überhaupt nichts mit dem Allocator aus der C++ Runtime Library zu tun (ausser das sich der Allocator dort Speicher holt). Und der Allocator muss sich nicht merken, wie groß ein dynamisch alloziiertes Array ist, wenn er die Informationen beim Freigeben wieder mit bekommt.
Wenn der Allocator gezwungen wird, diese Informationen zu speichern, dann sind diese Informationen zwangsläufig nur noch zur Laufzeit bekannt. Jede Optimierung, die möglich wäre, weil die Informationen bereits zur compile-Zeit bekannt sind, werden damit unmöglich.
HansKlaus schrieb:
c++-übliches undefined behaviour? also ich weiß, dass die cpu "mal eben so" einen neustart durchführt, wenn sie nicht-definierte zustände feststellt, weil so etwas den supergau schlechthin darstellt.
"undefined behaviour" ist ein stehender Begriff in der C++-Welt. Das ist unbedingt zu vermeiden und es hat sich auch keiner die Mühe gemacht, zu definieren, was in solchen Situationen zu passieren hat. double delete ist z.B. auch so ein Fall. Bei einer "üblichen" Implementierung eines heaps, wir ein frei gewordenes Stück Speicher einfach in eine Liste freier Speicher mit einer bestimmten Größe gehängt. Ein double delete führt in dem Fall dann einfach dazu, dass der gleiche Speicher zwei mal in der Liste hängt.
HansKlaus schrieb:
aber eigentlich wird mit delete nur ein tabelleneintrag in der form "anfangsadresse, endadresse" gelöscht, von daher gibt es da auch keine fehlermöglichkeit.
Wer diese Informationen von der C++ Runtime haben möchte, kann doch einfach std::vector verwenden.
