In our implementation, if you splice between two lists whose
allocators don't compare equal, the nodes get copied. Not a
big deal.
Good point. I just noticed that this won't break the complexity
requirements either, because the range version of splice is only
required linear complexity. Then again, this takes one potential
strength of splice() away: to move many elements in constant time. Then
the strength of splice() lies purely in avoiding the allocations and
deallocations.
I retract my opinion that splice() is a reason that makes good custom
allocation impossible.
Also not true. You can still write node allocators that maintain
pools of reusable nodes. Indeed, we provide several such allocators
with our Compleat Library, available at our web site as an add on
to VC++, gcc, and other popular compilers.
As I said in the other reply, you can rely on the support for the
unequal allocators. In general, I can't. I wonder if we will be able to
do portable stateful custom allocators in C++09..
Ok, so VC++ is able to take advantage of better allocation schemes. Why
is the std::allocator such slow?
Dunno. We find that sometimes the underlying malloc/free is slower
for some configurations. Microsoft also adds a layer of "secure"
P.J. Plauger
Dinkumware, Ltd.
[ comp.lang.c++.moderated. First time posters: Do this! ]