Charlls Quarra wrote:
--- El mié 2-mar-11, Oliver Kowalke escribió:
De: Oliver Kowalke 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
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 -- View this message in context: http://boost.2283326.n4.nabble.com/context-fiber-implementation-comments-tp3... Sent from the Boost - Dev mailing list archive at Nabble.com.