RFC on mt_allocator.h

[Stefan Olsson]

Felix Yen wrote:

> Benjamin Kosnik writes:
> >  Please, I beg you, document this allocator.
>
> I also beg.  I'm new here, so let me introduce myself. 

[...]

>
> At the very least, an allocator as sophisticated as the one you're  
> discussing should be accompanied by documentation that specifies its  
> intended applications and describes its design as well as its  
> limitations.  I would also like to see a brief description of the  
> performance test(s) used to qualify the allocator.  I realize that 
> this  is a tall order, but any sane person who's shopping for an 
> allocator is  going to look at GCC sooner or later. 

I could not agree more. As you might have seen in my emails in the past 
this started out just like your allocator - a immediate need to solve a 
problem. However the main focus right now (aside from the additions 
described in the rfc) is actual documentation that makes the allocator 
inner workings understandable so that it can be further improved by 
others than us.

>
>
> I know someone on this mailing list made the point that the default  
> allocator should perform reasonably well in most cases.  I strongly  
> agree.  In fact, I think the distribution only has to provide obvious  
> alternatives like the version that supports debugging, allocators 
> that  are used by the distribution itself, and maybe adaptors that 
> facilitate  using user-supplied classes or global functions as STL 
> allocators.   Since everyone seems to think that they're better off 
> writing their  own, let them. 

Once again, I agree - there will always be people that wants to reinvent 
the wheel - but the current default pool based allocator needs to be 
upgraded in order to support the widespread use of threaded applications 
for all those that does not want to spend weeks on developing their own 
allocator.

You're more than welcome to help out on the development of mt_allocator 
may it be documentation, testcases and/or features!

Brgds

/Stefan

>
>
>
> Felix
>