Re: [Boost-users] [intrusive] list compatibility with existing application-defined intrusive lists

Subject: Re: [Boost-users] [intrusive] list compatibility with existing application-defined intrusive lists
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2018-02-04 22:30:17

On 03/02/2018 21:42, Rahul Ramadas via Boost-users wrote:
> For example, I have an existing function (to be precise, a callback that 
> I pass to legacy C code), that accepts a struct list_head* that is 
> expected to contain a list of elements of a certain type. I want some 
> way to "wrap" this raw pointer in a type-safe intrusive list type that I 
> use as naturally as a boost::intrusive::list (iteration, modification, 
> etc.). I see no way to achieve this.
> 
> The way I see it, what I need is a boost::intrusive::list_ptr, a 
> container that doesn't actually own the list head, but rather, points to 
> a list head stored elsewhere. It would have the same interface as a 
> list, allowing me to push_back, clear, etc., but behaves as a pointer 
> when it comes to moves and copies. Additionally, there should also be a 
> boost::intrusive::const_list_ptr, which will not allow me to modify the 
> list, but still allows iteration and other non-modifying operations.
> 
> Unless, of course, there are already existing mechanisms to achieve 
> this. If anyone has any ideas, please let me know.

There is no way to do it with containers, you could use node algorithms 
directly. On the other hand there is some undocumented support to have a 
different header holding policy (header_holder_type), but it assumes the 
the header holder internally holds the header node (allocating it 
dynamically or by any other mechanism). There is no interface to modify 
this header holder to, say, set the a pointer to the header node.

In any case, I think having the possibility to hold the header node 
externally it's a useful extension to Boost.Intrusive.

Best,

Ion