On 8 July 2014 23:44, Niall Douglas wrote:
On 8 Jul 2014 at 17:03, Jonathan Wakely wrote:
On 5 July 2014 21:00, Niall Douglas wrote:
I am grateful for the clarification, but I think my original statement was correct yes? STL containers don't have a noexcept move constructor in C++ 11 due to allocators?
No, that's not correct.
It's because some implementations either need at least one node even in an empty container (which requires the moved-from object to allocate memory after it's move from) or because debugging "safe STL" implementations perform memory allocation during a move.
Although those reasons are related to memory allocation, they're not to do with Allocators, the same reasons would apply if everything used malloc().
I think we might be at cross purposes here due to my sloppy phrasing.
I didn't mean that allocators per se are at fault, I did mean that the present design of STL allocators are at fault.
And I still disagree. Some implementations want to allocate memory in their move constructors. Memory allocation might fail and throw an exception. I don't see how the STL allocator design has any bearing on that.
If they had a different design the issues you mentioned wouldn't constrain noexcept, though they probably would constrain something else even more important.
For example, a better allocator design could guarantee that zero sized allocations always succeed, or that known temporary allocations always use alloca(), or guarantee non-relocating reallocs, or copy on write page table duplicate maps. That sort of thing. Such flexibility would eliminate the constraints the present design imposes upon their users.
But would have no effect on whether move constructors that allocate memory can throw.