Re: [Boost-users] boost::unordered_map using boost::interprocess::cached_node_allocator compilation failure

Subject: Re: [Boost-users] boost::unordered_map using boost::interprocess::cached_node_allocator compilation failure
From: Daniel James (dnljms_at_[hidden])
Date: 2011-09-15 03:53:16

On 14 September 2011 22:35, Lenny Maiorani <lenny_at_[hidden]> wrote:
> Hi Boost-ers,
>
> I am trying to create a boost::unordered_map in a boost::interprocess::managed_shared_memory segment. This works fine until I try to change from using boost::interprocess::allocator to boost::interprocess::cached_node_allocator.
>
> It seems that the hash_bucket structure is deferring the key size calculation, but the cached_node_allocator needs the size at compilation time. Any ideas on how to make this work?
>
> Below is a sample attempt which displays my problem along with the GCC output.

The problem is that the unordered containers do something similar to:

    template <typename T, typename Allocator>
    struct node
    {
        typedef typename
            Allocator::template rebind<node<T> >::other alloc;
        typedef typename alloc::pointer;

        T value;
        pointer next;
    };

There's a circular dependency here - to get the type of 'pointer' the
allocator needs to be rebound to the type of the node, to get the
complete type of the node, the type of 'pointer' is needed. This isn't
a problem if the allocator can be instantiated for an incomplete type.
I suspect that this is an incompatibility that needs to be fixed in
boost.

I think the correct solution to using a void pointer type (not
'void*', the type from rebinding to void) for 'next', the problem is
that while C++11 requires an easy conversion from and to the void
pointer type, older versions of C++ don't. They're a bit ambiguous and
contain a sort of opt-out clause to allow for that, so I could
possibly assume that conversion is possible, but I really wanted to
only rely on the bare minimum allocator requirements. It's a case of
choosing which assumption to make. I'll have to think about it. I
suppose that now the allocator requirements in C++11 should be the
guideline.