On Wed, Aug 10, 2022 at 9:44 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Wed, Aug 3, 2022 at 5:55 PM Jason McKesson wrote:
> >
> > Broadly speaking, what you're asking for is not really viable.
> >
> > The problem with simplistic, fixed-bound allocators like these is that
> > it only works while communicating effectively with the container
> > itself.
> >
> > `vector`'s allocation strategy is entirely *opaque* to the user.
>
>
> std::vector has the "reserve(size_t)" method, taking away some of that
> opaqueness.
>
>
> > your example, how do you as the user of `vector` know that the first
> > `push_back` won't try to allocate more than 4 characters? There's no
> > requirement than, when using `push_back` on an empty `vector`, it will
> > allocate a buffer of no more than 4 values. There's no requirement
> > that calling `reserve(x)` will only allocate `x` items.
>
>
> Each allocator could be mandated to have a constexpr boolean member
> named "conservative".
>
> template<typename T, std::size_t t_capacity>
> class StaticAllocator {
> public:
> bool constexpr conservative = true;
> };
>
> When "conservative" is set to 'true', the container should never use
> the allocator to allocate more memory than the container needs.

Why would that be a property of the allocator and not the container? I
think this would also kind of break polymorphic allocators (that is,
they would have to either always use this flag or never use it), and
I'm not sure what the effects would be on scoped allocators.

Also, what does "needs" mean here? A deque for example is usually
implemented as a linked list of blocks, each containing some fixed
number of elements. If the deque has fewer elements than the block
size, or the begin/end don't land at the start or end of a block, is
that extra space "needed"?

And if it is needed, how is that "need" any different from those of
`std::vector`'s reallocation strategy? After all, both of these
implementations are necessitated by the standard. `deque` uses blocks
because insertions/removals from the head and tail is required to be
constant time. `vector` is required to "support (amortized) constant
time insert and erase operations at the end". If every insertion at
the end causes reallocation, then that complexity is not provided.

You're basically asking for the allocator to prevent the container
from doing its job.

> > Everything you want ultimately requires a tighter coupling between the
> > container and the allocator than C++ provides. The only way to resolve
> > this is to make some fundamental changes to the allocator/container
> > model.
>
>
> I have suggested one such small change.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals