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.


Agustín K-ballo Bergé.-

Boost list run by bdawes at, gregod at, cpdaniel at, john at