Re: [boost] ASIO into the standard

Subject: Re: [boost] ASIO into the standard
From: Daniel James (dnljms_at_[hidden])
Date: 2014-07-12 05:20:24

On 12 July 2014 01:49, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> On 11 Jul 2014 at 21:06, Daniel James wrote:
>> >
>> > 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 assume by allocators you mean specifically STL allocators?
>
>> I looked this up earlier, as I thought the same. 23.2.1.7 says:
>>
>> "Unless otherwise specified, all containers defined 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.
>
> The standard definitely means an STL allocator, not simply "an
> allocator"?

It refers to 17.6.3.5 which is the standard allocator requirements.

I've just been re-reading the standard, and it's subtle. The quote
about 'allocate' is for 'containers defined in this clause', the quote
for 'construct' is for 'components affected by this subclause', the
former could be just about the existing standard containers, the
latter about all containers that want to meet the standard
requirements. The allocator aware container requirements and
general/reversible/etc. container requirements don't mention anything
about allocation. So, if I'm reading it correctly, std::unordered_set,
std::vector, etc. have to always use 'allocate' to allocate memory,
but other containers that want to meet the 'allocator aware'
requirements don't have to use 'allocate' at all, just 'construct',
which I find surprising. It's possible that I've missed something, or
that it's an oversight. It might be worth asking on a standards list.

Although, if a container is designed to be standardized, the designer
will probably have to justify using allocators and not requiring
'allocate'.

> I have been lazy as it's test code, and implemented a move assignment
> like this for an internal item_type due to value_type.first being
> const:

I move the nodes over when possible (when the allocators propagate on
move or are equal), but copy the key otherwise.