Re: Implementation of forward_list (and compressed_pair)

[Ion Gaztañaga <igaztanaga at gmail dot com>]

Paolo Carlini wrote:
> Paolo Carlini wrote:
> > Ah! I think this is right! And, I must say, I'm "guilty" of having
> > sidetracked Ed to the issue of having a pair of allocators stored for
> > efficiency. Now I see that indeed thanks to the new variadic
> > allocator::construct one can construct in place using the same node
> > allocator (provided one adds an appropriate constructor for the node as
> > you are doing above).
> >   
> To wit, this kind of patch appear to work well for std::list.
>
> Paolo.

And it will surely work for also for stl_tree.h changing just 
_Rb_tree_node and in _M_create_node. Of course, same for unordered 
containers.

Off-side comment: The approach of creating allocators on the fly instead 
of storing them is also an option but for some stateful allocators (like 
some shared memory node pools) constructing a related allocator is not 
trivial and it might require a name lookup or similar to get a pointer 
to the "singleton" pool (e.g. Boost.Interprocess pool allocators). With 
heap allocators the linker/loader does this job but for shared memory it 
must be done when the allocator is constructed.

Regards,

Ion