* another

--
Phil Bouchard
Founder
C.: (819) 328-4743
> On Jul 25, 2021, at 5:14 AM, Phil Bouchard <boost_at_[hidden]> wrote:
> 
> I am currently abstracting / defining things that are not yet defined so I'll have to rewrite the example I provided later today.
> 
> But what I'm trying to abstract really is an allocator cache class optimized for LIFO & FIFO container types. It could be used for an container types but it would be optimized for queues and stacks.
> 
> --
> 
> Phil Bouchard
> Founder
> C.: (819) 328-4743
> 
> 
> 
>>> On Jul 25, 2021, at 12:24 AM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>> 
>> On Sat, Jul 24, 2021 at 7:01 PM Phil Bouchard via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>> 
>>> - Front / back (non middle) deletions and insertions will guarantee the allocations are contiguous (will keep block sizes together, organized and without holes in between);
>>> - The size of the pages will be directly proportional to the usage frequency so the greater the demand is, the bigger the memory pages will be thus less overall page allocations);
>>> - What I presented is perfect for LIFO container types, a similar specialization can be done with FIFO and other container types will use a generic specialization.
>>> 
>>> That will force the developers to think twice before using a specific container type of they really want speed.
>>> 
>> 
>> Do you think developers interested in performance *don't* think about
>> allocation patterns of their containers? Developers interested in the
>> absolute fastest performance for containers generally don't use
>> standard library containers anyway, since they will want control over
>> things that standard library containers don't give control over.
>> 
>> Also, what is a "LIFO container" and how are they different from "FIFO
>> containers"? I know what FIFO and LIFO mean, but I don't know how they
>> apply to *containers*. FIFO (ie: a queue) is not a type of container;
>> it's an *access pattern* for a container. LIFO is a stack, but again
>> that's a way of accessing a container. Now yes, you can write a
>> stack/queue class that exposes only the stack/queue interface. And you
>> could therefore call that a stack/queue container. But the actual
>> container structure underlying that interface is ultimately what we're
>> talking about.
>> 
>> At the end of the day, what does `some_allocator_type<T, std::vector>`
>> really know about how you intend to use that `vector`? Does it know
>> that you're going to use a LIFO access pattern? Because there are ways
>> of using `vector` that don't involve being a stack. And if you are
>> genuinely interested in LIFO access patterns, there are more efficient
>> data structures than using `vector`. And that's about more than just
>> how you allocate memory; it has to involve how you *use* that memory.
>> -- 
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals