Re: [boost] ASIO into the standard

Subject: Re: [boost] ASIO into the standard
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2014-07-24 19:31:44

On 12 July 2014 10:20, Daniel James <dnljms_at_[hidden]> wrote:
> 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.

Yes, that is pretty clear IMHO.

The standard talks about two very distinct things, "allocation
functions" and "allocators", the latter being what Niall is referring
to as STL allocators.

> 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.

I've tried to clarify a few things with
http://cplusplus.github.io/LWG/lwg-active.html#2261
and
http://cplusplus.github.io/LWG/lwg-active.html#2218
but I didn't notice that paragraph 8 only applies to the standard
containers, not to user-defined ones trying to meet the requirements.

> 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.

I want to make it possible for maps to store the elements in a union
of pair<Key, T> and pair<const Key, T> but there are a few changes
needed for that to work, including either forbidding user
specializations of std::pair or just requiring that pair<const A, B>
must be layout compatible with pair<A, B>, so users who specialize one
may need to specialize the other.