Am 02.03.2011 18:43, schrieb Charlls Quarra:
--- El mié 2-mar-11, Vicente Botet<vicente.botet@wanadoo.fr> escribió:
De: Vicente Botet<vicente.botet@wanadoo.fr> Asunto: Re: [boost] [context] implementation comments Para: boost@lists.boost.org Fecha: miércoles, 2 de marzo de 2011, 13:28
--- El mié 2-mar-11, Oliver Kowalke escribió:
De: Oliver Kowalke Asunto: Re: [boost] [context] implementation void(*)()>( fn, stacksize) );
the allocation is necessary for: - support of efficient move semantics - in order to accept arbitrary functions with arbitrary arguements in the ctor of a fiber - the type asym_fiber and sym_fiber should not depend on the passed function (== the specific signature aof
function to be executed by the fiber doesn't influence the type of asym_fiber/sym_fiber) => you can store fiber objects which managing functions with different signature in the same container
asym_fiber_object is a template storing the functor which will be executed by the fiber. asym_fiber_base is the interface asym_fiber_object dervies from. this pattern allows to hide the specific functor signature Oliver
Thats fine ;-), i'm not discussing the reason of having heap allocations in there; all i'm saying is that there should be the
to pass a custom allocator type (as a templater
Charlls Quarra wrote: the option for the user parameter, as is customary
for std:: libs) that these (any) allocations can be delegated to
The problem adding the Allocator as a template parameters is that it change the type. Note that Boost.Fiber follows here the design of Boost.Thread, which is on a std lib (C++0x)
Best, Vicente
what if it changes the type? i understand the point of making the type independent of the signature of the invoked handler, but i don't see why it needs to be extended to any sort of type parameter dependence.
So it seems that boost.thread doesn't provide a allocator parameter and it sounds like a limitation in it (unless i'm missing some point here). consistency alone shouldn't be a good reason if it means constraining usability without sound reasons
Charles
What you are referring to is a internal data-structure (namespace detail) and not intended to be used outside. Many of the stl container don't use their allocators - for instance std::list allocates its internal data structures with new (allocator can not applied) - therefore I believe it would not make sense to parametrize fiber with an allocator. Oliver