> In effect, you are assuming that your uninitialized and initialized variables straddle a page boundary
You are assuming that I am working with small data structures, don't use arrays of data, don't have large amounts of POD members, ... .
> That heap chunk descriptor before your block has to be written, triggering a page fault.
So you allocate one out of hundreds of pages? The cost is significantly less than the alternative.
> In that case your performance and memory usage are going to be highly unpredictable (after all, initializing a single thing in a page would materialize that whole page).
As opposed to initializing thousands of pages you will never use at once? Or allocating single pages when they are needed?
> Well, the default allocator for vectors will actually zero-initialize the new elements.
I reliably get garbage data after the first reserve/shrink_to_fit calls. Not sure why the first one returns all zero, I wouldn't rely on it.
> You are assuming that I am working with small data structures, don't use arrays of data, don't have large amounts of POD members, ... .
Sounds like a great set of use cases for explicit syntax to opt out of automatic initialization.
Reserve vs resize, yes.
Reserve will not initialize, but then you have to keep track of the real vector size on the side, inevitably leading to bugs. Alternatively, something like this https://stackoverflow.com/questions/15967293/how-to-make-my-... will make resize() leave the elements uninitialized.
> Reserve will not initialize, but then you have to keep track of the real vector size on the side
You already do that when you use push_back. It tracks the size for you, overallocates to amortize the cost of growing and most importantly does not initialize the overallocated memory before it is used, meaning pages will not be touched / mapped by the OS unless you actually end up using it. Giving you the benefit of amortizing vector growth without paying for the uninitialized memory it allocates behind the scenes for future use.
Directly accessing reserved memory instead of using resize was to check if the allocator zero initialized that overallocated memory. That the parts that are used end up initialized at a later point is entirely irrelevant to my point.
So your previous point:
> They double in size, right? Well, the default allocator for vectors will actually zero-initialize the new elements.
They double in capacity, not size when used with push_back. Which means exactly one new element will be initialized no matter how much uninitialized/unused/unmapped capacity the vector allocates for future use.