Re: [boost] ASIO into the standard

On 12 July 2014 10:20, Daniel James wrote:

On 12 July 2014 01:49, Niall Douglas 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 and pair but there are a few changes needed for that to work, including either forbidding user specializations of std::pair or just requiring that pair must be layout compatible with pair, so users who specialize one may need to specialize the other.