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. 188.8.131.52 says:
> "Unless otherwise speciï¬ed, all containers deï¬ned in this clause
> obtain memory using an allocator (see 184.108.40.206)."
> 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". :-)
> 220.127.116.11 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
> (18.104.22.168). 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk