This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: std::string::reserve()
- From: Paolo Carlini <pcarlini at suse dot de>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, Neil Ferguson <nferguso at eso dot org>
- Date: Wed, 24 Nov 2004 11:17:51 +0100
- Subject: Re: std::string::reserve()
- References: <402A9983.50600@eso.org> <402AAB6A.7070101@suse.de> <402AB08B.9060305@suse.de> <402B8521.9010706@eso.org> <402B883A.4060506@suse.de> <4035D65C.4050607@eso.org> <419DA7ED.4010808@eso.org> <20041123231556.4830b539.bkoz@redhat.com>
Benjamin Kosnik wrote:
Hi Neil.
http://gcc.gnu.org/ml/libstdc++/2004-02/msg00212.html
Can you make a bugzilla report about this?
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. 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...
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... ;)