Subject: Re: [boost] [fiber] ready for next review
From: AgustÃn K-ballo BergÃ© (kaballo86_at_[hidden])
Date: 2015-12-05 10:37:22
On 12/5/2015 12:05 PM, Oliver Kowalke wrote:
> 2015-12-05 15:03 GMT+01:00 AgustÃn K-ballo BergÃ© <kaballo86_at_[hidden]>:
>> 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.
> In class promise and packaged_task probably simply copy&paste the code from
> the StackAllocator snippets.
> What's wrong with allocator::allocate() + placement new instead of
> allocator::allocate() + allocator::construct()?
An allocator might do other stuff in `construct` besides placement-new
construction, which is what the default `std::allocator_traits` does. An
allocator might, for instance, choose to trace all calls and log them,
or it might choose to defer construction to some other allocator.
Allocators like `scoped_allocator_adaptor` inject additional arguments
and/or select different constructors to call (although I do not think
this applies here). An allocator might even reject to construct certain
types or use certain types of arguments, which they do so by failing to
instantiate `construct` (188.8.131.52 [allocator.requirements]/9).
Furthermore, keep in mind that `allocator::allocate` does not
necessarily return a **raw** pointer.
Using `std::allocator_traits` here would, besides giving some support
for C++11 allocators, also pick the right placement-new to call in the
case of nasty overloads (current code correctly qualifies `::new` but
fails to secure a `void*` argument). Also, use of the replaceable
standard library placement new requires `#include <new>`.
-- 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