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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14