On 12 July 2014 01:49, Niall Douglas
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.