`<string>`, `<vector>`: Contiguous containers should benefit from `allocate_at_least`

[frederick-vs-ja]

Currently nothing in MSVC STL calls the allocate_at_least member function of an allocator except the mandatory call in allocator_traits, which means that even if one adds allocate_at_least with the expected optimization to a provided allocator type, the behavior of STL doesn't change at all.

libc++ has made use of allocate_at_least via LLVM-D122877. I think MSVC STL should also do so.

[AlexGuteniev]

Normally MSVC STL allocation has the following call stack:

::operator new
malloc
HeapAlloc
RtlAllocateHeap

Although internally some granularity may exist, the allocation stores the size exactly.

This size can be known by using _msize which calls HeapSize. Here's a way to observe it:

int main()
{
    auto x = malloc(37);
    auto y = _msize(x); // y is always 37.
}

Tools. such as ASan or AppVerifier may detect out of bound accesses if we try to use more than told by HeapSize

There's an exception from the above stack, see _Big_allocation_threshold/_Big_allocation_alignment, but I'm not sure whether there can be some extra allocation observed, and I wouldn't want to utilize that even if there is.

[frederick-vs-ja]

Normally MSVC STL allocation has the following call stack:

::operator new
malloc
HeapAlloc
RtlAllocateHeap

Although internally some granularity may exist, the allocation stores the size exactly.

This seems only bound to the default std::allocator (which is used in most time, though). I don't think we can change the default std::allocator at this moment, because the corresponding core paper WG21-P0901 hasn't been voted in or implemented.

However, I think custom allocators may behave differently, see here.

[StephanTLavavej]

We talked about this at the weekly maintainer meeting and would be fine with such a PR.