Hi Michael and Pablo,

I won't be able to make the meeting due to the time but my feedback on the paper is as follows:

The comparison between this container and other memory-handling structures/functions isn't valid as there are many which do not support allocators, you've listed the ones which do.
The only comparison is between this container and other containers, which do support allocators.
That comparison is invalid because while not supporting allocators is inconsistent with the other containers, supporting them is inconsistent with how this container is used in the wild.

boost::static_vector and inplace_vector are designed for use on the stack, not the heap. That is the point of the container. Your examples of using pmr types with an inplace_vector, or storing an inplace_vector inside a pmr::vector, don't make any sense in context. Sure, you might want to store several inplace_vector's inside some kind of vector, but if you didn't want your inplace_vector to be stored on the stack - you wouldn't use inplace_vector. You'd use another type of vector+reserve() which isn't stored on the stack.

At this point I would vote against the paper, however if yourself or anyone else came up with valid examples of how using an allocator with an inplace_vector, instead of another type of vector+reserve() would be useful *in the wild* then I could be convinced otherwise. But theoretical musings are not worth considering.

ps. re: "std::vector is preferred over other containers in many cases because its use of contiguous memory provides optimal cache locality and minimizes allocate and deallocate operations."

You can in fact create a deque which has fewer allocate/deallocate ops than a vector, but nobody's implemented it yet.

On 15/05/2024 3:44 am, Michael Wong via SG14 wrote:

hi all, it seems we will still be able to hold an SG 14 call in June as it does not conflict with the St.Louis F2F. for the Wednesaay June 12 2-4 Et call, we were directed in Tokyo to give feedback to a paper P3160 because it was started in sg14 on

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3160r1.html

I have cc the author so that Pablo can give guidance on what kind of feedback is needed on the June sg14 call. thank you.

An Allocator-Aware inplace_vector
_______________________________________________
SG14 mailing list
SG14@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14

An Allocator-Aware inplace_vector

An Allocator-Aware `inplace_vector`