|
Boost : |
Subject: Re: [boost] [context] implementation comments
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-03-05 09:34:40
Am 05.03.2011 12:00, schrieb Sebastian Redl:
> On 04.03.2011, at 21:18, Oliver Kowalke wrote:
>
>> Am 04.03.2011 20:06, schrieb Sebastian Redl:
>>> On 04.03.2011, at 19:16, Oliver Kowalke wrote:
>>>> 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.
>>> I don't know what std::list implementation you are referring to, but it's buggy. A standard container has to use its allocator for *all* allocations. That's what rebind is for.
>>>
>> stl::set of gcc-4.4.5 does not use its allocator
>>
>> C++ standard 23.2.1:
>> '... are called only for the containers element type, not for internal types used by the container. [ Note: This
>> means, for example, that a node-based container might need to construct nodes containing aligned buffers
>> and call construct to place the element into the buffer. end note ]...'
> That clause only applies to construct() and destruct(), not to memory allocations.
> Here's the relevant citation, from C++0x 23.2.1p8:
> "Unless otherwise specified, all containers defined in this clause obtain memory using an allocator. [...]
> A copy of this allocator is used for any memory allocation performed, by these constructors and by all
> member functions, during the lifetime of each container object or until the allocator is replaced."
>
> If GCC's set uses plain new anywhere, it's broken. If it uses placement new to construct its internal structures, that's fine.
>
> Sebastian
then Scott Meyers is completely wrong?
23.2.1 - 8 deals with swap() operation in my C++ standard document
anyway I don't see relevant arguments that asym_fiber/sym_fiber should
add an allocator to the interface.
what about boost::thread and other constructs from the boost library?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk