Re: [container] Draft development plan for Boost.Container

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2024-05-21 19:31:29

On 21/05/2024 17:24, Andrey Semashev via Boost wrote:
> On 5/21/24 19:22, Niall Douglas via Boost wrote:
>> On 21/05/2024 06:03, Ion Gaztañaga via Boost wrote:
>>
>>> Lately I've been collecting some ideas about how to improve the library
>>> and keep it interesting/useful both for other Boost libraries and Boost
>>> users.
>>
>> Separating the algorithm from the container, or ability to use the
>> algorithm with a third party container implementation, would be a win.
> 
> Boost.Intrusive fits this niche.

Not exactly.

Boost.Intrusive requires you to inject stuff into your values.

What I'm thinking of is customisation points so you could override how 
Boost.Container implements containers and allocators. No need to modify 
your code or your values, you would just inject customisation points for 
your types.

In case the value add isn't obvious, Boost.Intrusive generally insists 
that you need to insert specific items and types into your values. The 
customisation points injection technique can, in some circumstances, let 
you take advantage of the value type's specifics to more tightly encode 
the information the container needs to store per value.

For example:

struct value_type
{
   uint64_t field1: 40;
   uint64_t unused1: 24;
   uint64_t field2: 40;
   uint64_t unused2: 24;
   uint64_t field3: 40;
   uint64_t unused3: 24;
};

template<> struct boost::container::read_left<value_type>
{
   value_type *operator()(const value_type *v) const
   {
     return 
(value_type*)(uintptr_t)(v->unused1|(v->unused2<<24)|(v->unused3<<48));
   }
};

I appreciate this is a bit niche, but it's a big cause of me having to 
reinvent things locally, because I need tighter data layout than Boost 
stuff allows me.

Niall