Patch 2: speeding up the basic_string modifications

[Ryszard Kabatek]

Carlo Wood wrote:
> 
> 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.
Yes, create does not change the value of the __capacity parameter:
_S_create(size_t __capacity, const _Alloc& __alloc)


> 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.
If one wants for example 512 bytes he has to call reserve(512).
My patch does not affect the reserve member function, reserve does not use _M_mutate.

> 
> 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.
> 
Simple things we should keep simple... 
We should not change the _Rep::create function. There is only one place where we need
the expanded capacity - _M_mutate.
My patch does optimize the automatic resizing in string modification functions.
I hope it will be applied before the 3.01 release.


Regards
-- 
Ryszard Kabatek