Re: [boost] [context] implementation comments

Subject: Re: [boost] [context] implementation comments
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-03-04 13:16:27

Am 02.03.2011 18:43, schrieb Charlls Quarra:
>
> --- El mié 2-mar-11, Vicente Botet<vicente.botet_at_[hidden]>  escribió:
>
>> De: Vicente Botet<vicente.botet_at_[hidden]>
>> Asunto: Re: [boost] [context] implementation comments
>> Para: boost_at_[hidden]
>> Fecha: miércoles, 2 de marzo de 2011, 13:28
>>
>> Charlls Quarra wrote:
>>> --- 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
>> 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
>
> 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