Re: [boost] Could the custom allocator for flyweight hashed_factory be the boost::interprocess::allocator?

Subject: Re: [boost] Could the custom allocator for flyweight hashed_factory be the boost::interprocess::allocator?
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2013-06-25 06:07:14

On 24 June 2013 18:56, Jin Chen wrote:
> I want to use boost::flyweight to do the dedupilcation of
> boost::interprocess::basic_string object. I wrote a small test program for
> that. In my program:
> The flyweight works fine with the interprocess::basic_string which uses the
> interprocess::allocator only with the default hashed_factory. The default
> hashed_factory is ideal except that it uses std::allocator instead of
> interprocess::allocator. I followed the
> http://www.boost.org/doc/libs/1_53_0/libs/flyweight/doc/tutorial/configuration.html#hashed_factory
> specifier
> of a custom hash_factory which can change its allocator to the interprocess
> one, but then got insanely long compiler error that is super hard to
> decode...
>
> Right now, I don't know if only use interprocess::allocator in
> interprocess::basic_string alone will make the flyweight object be shared
> by multiple process, guess probably not... Then wonder whether that I
> didn't use the right syntax for custom hashed_factory or flyweight is
> compatible with boost::interprocess at all... If it is compatible, what's
> the right syntax for that? How shall I change my code?
>
> Below is a test program attached. The code could compile now with
> flyweight's default hashed_factory. The goal is to make it compile with
> ShmStringHashedFactory which use the interprocess allocator.

I think the problem is that flyweight wants to default-construct the
holder_arg, but interprocess allocators are not default constructible.