std::string::reserve()

[Neil Ferguson]

Paolo Carlini wrote:
> Benjamin Kosnik wrote:
> 
>> Hi Neil.
>>
>>>  http://gcc.gnu.org/ml/libstdc++/2004-02/msg00212.html
>>>   
>>
>> Can you make a bugzilla report about this?  

Will do - tonight, after the meeting I'm about to have. Do you want the 
old patch included in the bugzilla report?

> Hi everyone and sorry for late replying: I was working on something else...
> 
> The issue is largely not present in the current sources as a by product 
> of recent work, cleaning-up and improving _S_create: basically, now we 
> don't use anymore subpagesize. Strictly speaking we can still carrying 
> out unnecessary memcpy in situations involving shrink-to-fit (*) && 
> larger strings, but, IMO, perhaps we can live with that in the current 
> basic_string implementation. 

I'd noticed that you were doing work there, but hadn't had the time to 
look more closely (current project proving awkwardly slow). At some 
point - i.e. weeks from now - I'll need to see how my old patch relates 
to the current CVS. I basically brought it up now in the hopes that it 
would be easy enough/someone else would want it enough to put it in.

> More specifically, I don't like the idea 
> of, so to speak, anticipating in reserve the intentions of _M_clone , 
> using at this upper level of abstraction a knowledge of _M_clone inner 
> logic... Please, let me think about this issue a little more...

I vaguely seem to recall lifting out the size calculation logic into a 
separate method, so _M_clone and reserve could both call on it from one 
place, if that helps any.

> Thanks!
> Paolo.
> 
> (*) The very idea of shrink-to-fit, as we discussed in the original 
> exchange, is rather special for string: f.i., people coming from vector 
> don't even try it, as a simple reserve(0), I mean... ;)

Shrink-to-fit became significant for me when I discovered that users of 
libstdc++ here at ESO were reading large blocks of data from files into 
strings, without knowing how big the blocks were until reaching the end 
of said blocks.

One result of this is that the exponential allocation policy can end up 
allocating substantial amounts of memory which gets left unused, and it 
would be nice to have the option of reclaiming it this way.

Neil.