Quote Originally Posted by nuzzle View Post
But the performance gap has constantly been narrowing. And old truths may quickly become outdated. For example what you say about the heap and multithreading is likely to be outdated post C++ 11.
There will ALWAYS be a non-zero cost associated with allocation/deallocation. Multithreading may make the effects more dramatic due to synchronisation needs.

I'm not sure how or even if at all C++11 can make any change to this. how would a compiler know that
Code:
std::string* foo()
{
   return new std::string("foo");   // Which allocator ?
}
automatically needs to use a different heap depending on the thread this was called from? And if it can decide... this then has an "undefined" allocator. so what happens with the type ? is this a plain std:string or is if different from the "same" std::string made from another thread. Right now, the explicit allocator means they're different types.

ok, so maybe it uses thread local storage to do this, but a compiler cannot guarantee this will even work. What about deallocation. Who's the guarantee that it'll be deallocated on the same thread ? C++11 cannot remove the need for a heap to need synchronisation (which you CAN do for extra performance with a custom allocator if you know it won't ever be used cross-thread).

maybe it could decide on a heap per allocation/new as from what thread initiated it, but I.m.o. that would probably be more of a problem as a general approach than an actual benefit. Maybe there is a good reason for not wanting separate threads, so how do you override the default behaviour ?

So IMHO, I doubt any "automatic" system for allocators for multithreading is going to happen. Although I can see them adding custom thread-based allocators STL alongside the current single one, but you'll have to explicitely define your classes to use them.
Then again... i might be wrong