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

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

On Thu, Nov 29, 2001 at 05:13:15PM -0600, Loren James Rittle wrote:
> >> comment that, under the current implementation, you can't just change
> >> _MAX_BYTES?
> 
> > No, I didn't.  Where is it, and I'll go look?
> 
> Not a very good comment, but from include/bits/stl_alloc.h :
> 
> private:
>   enum {_ALIGN = 8};
>   enum {_MAX_BYTES = 128};
>   enum {_NFREELISTS = 16}; // _MAX_BYTES/_ALIGN

Oh, that.

The SGI code, somewhere, had a note that certain compilers had problems
calculating the quotient while creating an enum.  Since gcc doesn't have
that difficulty, I've changed the code in my local tree to be the obvious

    enum {_NFREELISTS = _MAX_BYTES / _ALIGN};

and the resulting object code was the same.  But I haven't checked in the
cleanup patch yet (have you sent me the second round of changes, btw?),
so the CVS code is still the "fragile" form.


> Just be careful if you ever change any one of them or expose the value
> to be set by the user.

Yes.  Replacing magic numbers by compiler-computable constants is easy,
but I have no good ideas on how to expose either of these to the user
(even in a read-only fashion).  The default template parameters were my
only off-the-top-of-my-head solution.  :-)

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