Subject: Re: [boost] [context] implementation comments
From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2011-03-07 04:44:28
On 05.03.2011 15:34, Oliver Kowalke wrote:
> 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 container’s 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?
I don't know. What did he say?
>
> 23.2.1 - 8 deals with swap() operation in my C++ standard document
Try 23.1p8 in the C++03 standard.
>
> 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?
I wasn't making that argument. I was just saying that an allocator, if
there was one, would be used even for internal data.
Sebastian