[lockfree] freelist_stack::allocate and freelist_stack::deallocate should not be private
Hey all, Currently, the allocate/deallocate functions et.al. in lockfree::detail::freelist_stack are private. This inhibits reusing this class for implementing other lock-free datastructures as it's not possible to allocate anything which has not a constructor taking 0, 1, or 2 arguments (those are supported explicitly by exposing overloads for freelist_stack::construct). Would it be possible to make the mentioned functions 'protected' instead? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
Currently, the allocate/deallocate functions et.al. in lockfree::detail::freelist_stack are private. This inhibits reusing this class for implementing other lock-free datastructures as it's not possible to allocate anything which has not a constructor taking 0, 1, or 2 arguments (those are supported explicitly by exposing overloads for freelist_stack::construct).
Would it be possible to make the mentioned functions 'protected' instead?
hm, i see your point. however freelists are not really part of the public API. iac, i'd somehow prefer to have an API like: template <class... Args> T * construct(Args&&... args) but for the time being, making these functions protected is ok to me. tim
Currently, the allocate/deallocate functions et.al. in lockfree::detail::freelist_stack are private. This inhibits reusing this class for implementing other lock-free datastructures as it's not possible to allocate anything which has not a constructor taking 0, 1, or 2 arguments (those are supported explicitly by exposing overloads for freelist_stack::construct).
Would it be possible to make the mentioned functions 'protected' instead?
hm, i see your point. however freelists are not really part of the public API. iac, i'd somehow prefer to have an API like: template <class... Args> T * construct(Args&&... args)
but for the time being, making these functions protected is ok to me.
hm, really not sure about this, mainly because freelist_stack::allocate and fixed_size_freelist::allocate have a different interface. but what's your specific use case? tim
Currently, the allocate/deallocate functions et.al. in lockfree::detail::freelist_stack are private. This inhibits reusing this class for implementing other lock-free datastructures as it's not possible to allocate anything which has not a constructor taking 0, 1, or 2 arguments (those are supported explicitly by exposing overloads for freelist_stack::construct).
Would it be possible to make the mentioned functions 'protected' instead?
hm, i see your point. however freelists are not really part of the public API. iac, i'd somehow prefer to have an API like: template <class... Args> T * construct(Args&&... args)
That's be fine with me, but currently you only support up to two constructor arguments.
but for the time being, making these functions protected is ok to me.
hm, really not sure about this, mainly because freelist_stack::allocate and fixed_size_freelist::allocate have a different interface. but what's your specific use case?
We have a lockfree_dqueue implementation which uses freelist_stack underneath. The elements (nodes) pushed on the queue take 4 constructor parameters, which makes it impossible to use the current construct() overloads. Thus we resolve to call allocate() followed by the explicit construction in place of the new node. Adding more constructor overloads (taking more than 2 parameters) would solve the issue for us as well. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu
participants (2)
-
Hartmut Kaiser -
Tim Blechmann