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. 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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/