microsoft / STL

MSVC's implementation of the C++ Standard Library.
Other
10.06k stars 1.48k forks source link

P0843R14 `<inplace_vector>` #4766

Open StephanTLavavej opened 2 months ago

StephanTLavavej commented 2 months ago

WG21-P0843R14 <inplace_vector>

Feature-test macro:

#define __cpp_lib_inplace_vector 202406L

Note: We're focused on implementing the remaining library-only features in C++23. Until that's done, we will NOT be accepting PRs for C++26 features.

vasama commented 2 months ago

I have implemented this here: https://github.com/vasama/MSSTL/tree/feature/inplace_vector

When you start accepting C++26 features, I will be happy to reopen and update my PR. Please comment in this issue so that I receive a notification about it.

frederick-vs-ja commented 2 months ago

A proxy object for container/iterator debugging will make the container totally non-trivial, which is fine for all containers but array and inplace_vector. The problem is more severe for inplace_vector because the valid range of an inplace_vector object can vary among its lifetime.

Do we want to add a proxy object (but shouldn't be dynamically allocated if added) for debugging when it's allowed to do so?

StephanTLavavej commented 1 month ago

Dynamically allocated proxy objects are a bane, and we should avoid adding any more.

There's no point in container-internal proxy objects - their whole purpose is to allow iterators to find their parents after swapping/moving. (Note the distinction between them and sentinel nodes. Container-internal sentinel nodes work because they don't remain valid after swapping/moving.)

vasama commented 1 month ago

In my implementation the debug iterator currently contains a pointer directly to the size member of the inplace_vector, which is a null pointer in the case of zero capacity. This is used by the iterator itself to detect out-of-bounds accesses. The vector itself detects its own iterators using the data pointer also stored in the iterator.