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
<[email protected]> 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
