|
Boost : |
Subject: Re: [boost] ASIO into the standard
From: Bo Persson (bop_at_[hidden])
Date: 2014-07-12 05:41:26
Daniel James skrev 2014-07-11 22:06:
> On 11 July 2014 20:49, Glen Fernandes <glen.fernandes_at_[hidden]> wrote:
>> On Fri, Jul 11, 2014 at 12:18 PM, Felipe Magno de Almeida
>> <felipe.m.almeida_at_[hidden]> wrote:
>>>
>>> This looks very arbitrary to me. Is there any wording in the standard
>>> that supports that allocators have to be used only for allocation of
>>> value_type (or classes that has a value_type in it)?
>>>
>>
>> My understanding is that the allocators have to be used for all
>> dynamic allocation. If this is not explicitly worded in the standard,
>> then it should be. Otherwise allocators simply are not as useful with
>> any other interpretation.
>
> I looked this up earlier, as I thought the same. 23.2.1.7 says:
>
> "Unless otherwise speciï¬ed, all containers deï¬ned in this clause
> obtain memory using an allocator (see 17.6.3.5)."
>
> Which suggests to me that all allocation is done using the allocator.
> I suppose debug info could be considered something that isn't obtained
> by the container, as it can be external, but I wouldn't have thought
> that for things like buckets.
Well, it says "obtain memory", not "obtain *all* memory". :-)
>
> 23.2.1.3 says:
>
> "For the components affected by this subclause that declare an
> allocator_type, objects stored in these
> components shall be constructed using the
> allocator_traits<allocator_type>::construct function and
> destroyed using the allocator_traits<allocator_type>::destroy function
> (20.7.8.2). These functions
> are called only for the containerâs element type, not for internal
> types used by the container."
>
> But that's specifying construction, not allocation (btw. I get this
> wrong in unordered, I'll fix it soon).
Right. At least one implementation used construct and destroy on
internal pointers, like node pointers in std::list. This section
clarifies that they should not do that.
Bo Persson
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk