Re: Patch 2: speeding up the basic_string modifications

[Carlo Wood <carlo at alinoe dot com>]

On Thu, Jul 12, 2001 at 10:33:58AM +0200, Ryszard Kabatek wrote:
> ! 	  _Rep* __r = _Rep::_S_create(__new_size, __a);
...
> +       size_type __new_capacity = _M_rep()->_M_is_shared() ?
> +                                  __new_size : // _M_leak_hard
> +                                  (__new_size < 17 ? 32 : __new_size*2);
> +       // We get an exception. OK
> +       if (__new_size > _Rep::_S_max_size)
> +          __new_capacity = __new_size;
> +       else if (__new_capacity > _Rep::_S_max_size) // Avoid an exception. OK
> +          __new_capacity = _Rep::_S_max_size;
> + 
>   	  allocator_type __a = get_allocator();
> ! 	  _Rep* __r = _Rep::_S_create(__new_capacity, __a);

A few questions,

1) will string::capacity() return the exact same value as passed to _Rep::_S_create?
   If not I propose a different name, instead of __new_capacity.
2) wasn't the consensus that the growth should be such that it would be a
   a power of two *minus* the malloc administration overhead for sizes under
   the page size, and a multiple of the page size above that?  It seems to me
   that this patch might -say- try to allocate a capacity of 512 bytes, resulting
   in a memory allocation of 1024 bytes (512 bytes + 4 bytes of malloc administration),
   which is a waste of memory.

Having dealt with this _exact_ type of problem before, I feel the need to warn everyone
that it is VERY easy to make mistakes here (allocate the wrong number of bytes) and
therefore urge to create a new, seperate function, with well-defined parameters that
will do the calculation from 'needed space' --> { 'size-to-pass-to-malloc/new' }.
I feel this function will become complex, or at least sensitive to bugs, so it is good
to have it in one place.

-- 
Carlo Wood <carlo@alinoe.com>