Re: Less good ;-) results from Rittle's string allocator

[Phil Edwards <pedwards at disaster dot jaj dot com>]

On Thu, Nov 29, 2001 at 01:12:59PM -0400, Brad Spencer wrote:
> >  new:      __default_alloc_template<true,0, _MAX_BYTES=256>
> > 
> > or something similar.  Then basic_string can have its own memory
> > pool.
> 
> This would be excellent for my purposes (I write a lot of libraries
> for others as well as a lot of applications) because I could take some
> code that requires dynamic allocation of realtively large chunks and
> instantiate my own allocator.  Of course, it would be non-standard,
> but that's inevitable (isn't it?).

Depending on any particular allocation strategy is non-standard, yes.
I do feel we need to give the users more control over what strategy is used.

Even if the off-the-cuff idea above were implemented -- and it /is/ ugly
as sin :-) -- we couldn't recommend that users make use of names in the
implementation namespace.  They'd have to be wrapped and exposed somehow.


> It might also be reasonable to let me specialize the _ALIGN
> (well, really the _NFREELISTS) under such circumstances.  I might not
> need 8-byte granularity.  For the example above, it would be a waste.

We have to be careful not to violate the requirement that the memory
returned by a standard-conforming allocator is properly aligned for any type.
Other than that, yeah, I could see this too.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams