mt_allocator issues.

Dhruv Matani dhruvbird@gmx.net
Sat Mar 13 15:35:00 GMT 2004


On Sat, 2004-03-13 at 20:50, Stefan Olsson wrote:
> Hi Dhruv,
> 
> you are right. The original version was SGI style:
> template<int __inst> class __mt_alloc
> and since __inst was unused (and set to zero) there was only one 
> instance. However this changed when it was turned into a standards 
> compliant allocator:
> template<typename _Tp> class __mt_alloc
> 
> As of right now (late saturday afternoon) I'm not sure if this is a good 
> or bad thing, but it was never the less not originally intended this way!
> 
> Is it possible (through keywords/compiler options) to get the static 
> members "application  wide" instead of one copy per template? Or do we 
> have to define them elsewhere to get back to square one?

I would rather leave that to the maintainers but just to provide an
alternative:

1. Make __mt_alloc non-templated and make a new template wrapper which
derives from the non-templated one.

2. Make the static data part of a separate class, and make mt_alloc
derive from that.

3. Use an unnamed namespace.

All 3 seem quite reasonable to me, though, time-wise, 3 would be the
best.



> Brgds
> 
> /Stefan
> 
> Dhruv Matani wrote:
> 
> >Hello,
> >
> >Form the comments at the stat of the file:
> > /**
> >   *  This is a fixed size (power of 2) allocator which - when
> >   *  compiled with thread support - will maintain one freelist per
> >   *  size per thread plus a "global" one. Steps are taken to limit
> >   *  the per thread freelist sizes (by returning excess back to
> >   *  "global").
> >
> >But, it seems that currently, it is maintaining a freelist per size per
> >thread per type on which it is being instantiated.
> >
> >Ok, I may be wrong, but just a hunch.
> >
> >Is this what was intended?
> >
> >
> >
> >
> >
> >
> >  
> >
-- 
	-Dhruv Matani.
http://www.geocities.com/dhruvbird/

Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html



More information about the Libstdc++ mailing list