Boost logo

Boost :

Subject: Re: [boost] [fiber] ready for next review
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-12-05 09:27:09


On 12/5/2015 11:18 AM, Oliver Kowalke wrote:
> 2015-12-05 15:03 GMT+01:00 Agustín K-ballo Bergé <kaballo86_at_[hidden]>:
>
>> On 12/4/2015 11:48 AM, Agustín K-ballo Bergé wrote:
>>
>>> On 12/4/2015 4:47 AM, Oliver Kowalke wrote:
>>>
>>>> 2015-12-03 22:21 GMT+01:00 Agustín K-ballo Bergé <kaballo86_at_[hidden]
>>>>> :
>>>>
>>>> Yes, in the documentation.
>>>>>
>>>>
>>>>
>>>> documentation might need some updates - my announcement was primarly
>>>> focused to the source code
>>>>
>>>
>>> Fair enough, I was misguided by the "ready for next review" subject as
>>> well as the announcement that requests from the review have been
>>> addressed. This is obviously not the case, but we can still make a lot
>>> of progress based on source code adjustments only.
>>>
>>
>> I found an unusual pattern in the code, where memory is allocated via an
>> allocator's `allocate` but afterwards `construct` is side-stepped and
>> placement new is used instead. This breaks proper allocator support.
>> Curiously `destroy` is correctly used down the line.
>>
>> Furthermore, from a cursory look it seems C++11 allocators are not
>> supported. The code assumes a C++03 allocator interface. If it is
>> intentional then this requirement should be documented.
>>
>
> it is not an ordinary allocator - it's a 'stack allocator'
> placement new is used to allocate the control-structure on the fiber-stack
> (instead on using new -> heap)

I was actually referring to `promise` and `packaged_task`. Is that the
case there too?

If that means an argument whose type is `Allocator` has stronger
requirements than those expected by the standard library it should be
documented accordingly.

Regards,

-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk