[libcxx-commits] [libcxx] [libc++] Implement P0843R14: `inplace_vector` (PR #204008)
William Tran-Viet via libcxx-commits
libcxx-commits at lists.llvm.org
Fri Jun 19 09:56:40 PDT 2026
smallp-o-p wrote:
> Just for the record, I'd really like us to look into making this type as compact as possible before making the ABI stable. Specifically, I'd like us to explore:
>
> * putting the size into the tail padding of the last object
>
> * using tombstone traits to check whether the last element exist and if not have a size variable there. If it exists we know that we're full.
>
>
> If people have more ideas how to make this compact I'm happy to talk about that as well of course.
I've done some thinking on the methods you proposed:
> putting the size into the tail padding of the last object
This one is (I think) impossible because `data()` is a public API, meaning for an `inplace_vector<T,N>` with `size()` == `N` it's valid to write to `data()[N-1]`, where the padding bits would then get zeroed and corrupt the vector's state. I'm also unsure of an approach to this that is `constexpr` friendly since `[[no_unique_address]]` doesn't apply for C arrays, which leaves us with `reinterpret_cast` shenanigans which I believe will always run into UB.
> using tombstone traits to check whether the last element exist and if not have a size variable there. If it exists we know that we're full.
This one I think is doable but we'd be limited to `size_type`s where `sizeof(size_type)` <= `sizeof(T)`, which I think is valid for quite a few types in the standard library. I remembered you have #98498 open, but it's been a while, and I'd like to know if you want that work to finish first before continuing with `inplace_vector`, or if you're fine with letting this work get merged as experimental, and then adding `tombstone_traits` whenever that's done.
https://github.com/llvm/llvm-project/pull/204008
More information about the libcxx-commits
mailing list