Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c++.moderated    |    Moderated discussion of C++ superhackery    |    33,346 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 31,566 of 33,346    |
|    =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to All    |
|    Re: can someone shed light upon std::vec    |
|    13 Oct 11 16:47:25    |
      b774ce97       From: daniel.kruegler@googlemail.com              Am 13.10.2011 23:08, schrieb ps:       > I recently ran into some problems using std::vector. to my shock i       > found that the binary i was running ballooned to 3 GB in size. I       > figured out that the code had no reserve() on the vector container.       > But i didn't know this could pose such a grave situation.              You are describing your use-case very diffuse, so it is hard to give a       reasonable answer to the implied question. std::vector has a memory       allocation scheme, that will basically double it's capacity, when a new       memory request exceeds the current capacity (exponential grow strategy,       the more precise factor is the golden ration ~1.5). So, if you had 1.5       GB allocated, but need more memory for the next insertion, the new       memory will likely end in about 3 GB. This strategy is theoretically       optimal under a simple use model and helps keeping the number of       reallocations and memory copies in a good balance. But once you can       provide further information about the expected final maximum size, you       should definitively take of that and reserve this expected size early.              HTH & Greetings from Bremen,              Daniel Krügler                     --        [ See http://www.gotw.ca/resources/clcm.htm for info about ]        [ comp.lang.c++.moderated. First time posters: Do this! ]              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca