Daryle Walker wrote: > > That's an invalid argument, since the STL containers give you a default > value for the allocator argument, which makes containers work out of > the box, and the default is "for free."
I'm afraid it is not. The allocator parameter has a cost. It (a) prevents some very useful optimizations, (b) implementations that take it seriously (i.e. respect ::pointer, ::construct etc) make me suffer a measurable abstraction penalty. >> Bugs that have no workarounds are always fixed first. :-) > > You're making a worse assumption here. Who says that the need for a > different allocator class is because the default one > has-bugs/is-slow/plain-old-sucks? I say that the primary motivation to customize memory management details is that the default memory manager is slow. The standard allocators have a somewhat different story. They were originally intended to encapsulate the memory model, not the memory management details; this was in the near/far days. The original STL did its own memory management (free lists) independent of the allocator argument. Someone that has actually been present at the relevant meetings can fill the details why the allocators are now what they are (I'm tempted to use Alexander Terekhov's favorite characterization here :-)). > There can be an orthogonal need for a different allocator class, which no > improvement on the default one can fix. Oh yes, there "can be". And there "can be" a need for something else, too. > In this case, the Java user is 100% screwed since they can't change > the memory manager at all. [...] My point exactly. This is why the Java memory manager beats C++'s memory manager in the long run, because the user can't fix it. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
