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
-- 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