V
Wenn es um zeitkritische sachen geht, fliegst aber mit Vector auf die Nase ! Vector ist nun mal saulangsam, wenn es um Groessenaenderungen geht. Viele weichen aus dem Grunde auf C in solchen faellen aus.
das passiert aber nur nubes, die gerade ihr c-buch beiseitegelegt haben, seit 3 wochen c++ angucken und noch nix gerallt haben.
netterweise geht nämlich realloc immer dann nicht, wenn mans brauchen würde. ein ausweichen auf malloc statt new bringt nullinger. will man mehr speed (nicht amortisiert kleinere allokierungszeiten als std::vector, das klappt eh nicht gut, sondern kleinere maximalzeiten, also weg mit dem gelegentlichen ruckeln), so denke man an ein ausweichen auf std::queue oder hampele selber mit dem os rum (einfach mal fett virtuellen speicher saugen und nachher erst bei bedarf, optimalerweise über guard pages physikalisch allokieren).
warum ist vector eigentlich saulangsam? wenn man bei jedem überlauf die größe verdoppelt und mit ner größe von nur 100 anfängt, dann hat mal für 1000000 eingefügte datensätze gerade mal 14 verdopplungen erlitten und weniger als 2000000 sätze kopiert. neulich in diesem forum las ich, man nehme verkettete listen gerne, weil man sie in konstanter zeit wachsen lassen kann. korrekt. konstant ist das, wenn man 1000000 mal ein malloc/new aufruft. aber ist es durchschnittlich schnell? leider fehlt in den büchern oft, daß man sich mit malloc/new kleine arrays holen darf, die man dann verkettet. keine kopierkosten, nur 1000 malloc/new und konstante zeit.
danach isses wurstegal, ob man new oder malloc, ob man c++, c, assembler, pascal oder java nimmt.
man soll nicht c deshalb nehmen, weil man im vorfeld eine unangemessene datenstruktur gewählt hat.
