This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: std::string::reserve()
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.