This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: mt_allocator issues.
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