On 25/09/11 12:55 AM, Andrei Alexandrescu wrote:
On 9/24/11 9:33 AM, dsimcha wrote:
On 9/24/2011 2:10 AM, Andrei Alexandrescu wrote:
On 9/23/11 22:30 CDT, dsimcha wrote:
On 9/23/2011 11:25 PM, Robert Jacques wrote:
On Fri, 23 Sep 2011 15:53:46 -0400, Jonathan M Davis
<jmdavisp...@gmx.com> wrote:
No. I cannot build an efficient and safe appender on this API.
The resize() fix you requested is going to get implemented. I just
haven't actually added it yet.
Then we might be hasty to vote this in. Ideally Phobos should be
integrating tried and true APIs.
I wish we voted allocator in once it's used throughout std.container to
great effect.
Andrei
I see your point, but at the same time this does create a
chicken-and-egg problem. The use case that inspired me to work on
allocators is much simpler: Allocating simple temporary objects in
performance-critical functions. I don't have any plans to do containers
and I don't know of anyone else who does in the short term. Is there a
way to avoid waiting indefinitely to get allocators into Phobos?
I plan to work on containers, and part of the work is to integrate
allocators.
There are two basic paths from here. One is to make the allocator a
template parameter a la STL. The other is to define a dynamic allocator
interface and use it.
Making the allocator a part of the container type would go the STL way,
and STL allocators are essentially a failed experiment. I'm only
partially clear on why it has failed, but it does seem that part of the
reason was making the allocator a template parameter.
Defining and using an allocator interface would have a small speed
impact (i.e. allocation would entail an indirect call) but I think that
would be acceptable.
Andrei
I would like to say something here as someone that uses allocators in
C++ every single day at my day job: STL allocators are useless and no
one uses them in the way they were intended. Everyone I know defines a
runtime polymorphic allocator that is used by all containers and then
derives from that to implement different allocators.
The problems with STL allocators are listed here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#std_allocator
It's a document by a large game developer, but none of the allocator
complaints are specific to game development. Many of the same concerns
are raised here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1850.pdf
Also note that even though we obviously care a lot about performance,
we're fine with the cost of the virtual call on allocation. If you care
about performance then you shouldn't be allocating often in the first
place. We'd care a lot more about the code bloat caused by instantiating
different templates for each different allocator we use.
In short, I believe that templating containers on their allocator would
be a very poor decision. It was tried in STL and it failed miserably.
Let's learn from its mistake.
