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