
--- El mié 2-mar-11, Oliver Kowalke <oliver.kowalke@gmx.de> escribió:
De: Oliver Kowalke <oliver.kowalke@gmx.de> Asunto: Re: [boost] [context] implementation comments Para: boost@lists.boost.org Fecha: miércoles, 2 de marzo de 2011, 2:52
also, both asym_fiber and sym_fiber have allocations;
asym_fiber.hpp:51
return detail::asym_fiber_base::ptr(
do_return
? new detail::asym_fiber_object< void(*)() >( fn, stacksize, detail::asym_fiber_base::do_return) : new detail::asym_fiber_object< void(*)() >( fn, stacksize, detail::asym_fiber_base::do_not_return) );
sym_fiber.hpp:51
return detail::sym_fiber_base::ptr(
new detail::sym_fiber_object< 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 the 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 option for the user to pass a custom allocator type (as a templater parameter, as is customary for std:: libs) that these (any) allocations can be delegated to Charles