------- Comment #7 from neundorf at kde dot org 2006-09-12 20:34 ------- ... > "problematic" are string assigns, not += and you are moving the reserve > *after* the assign.
Yes, but in the every assign the capacity would still be lost. This would mean the reserve would happen once after each assign, and not in every iteration of the loop. This is obviously better then my first naive attempt, where it happend in (almost) every loop, but it would still be a bit slower than doing the resize()/reseve() once completely outside the two loops and the carefully avoid the resizing completely inside the loops. (... and since you're the right person I just ask) I guess assign(const char* buf, unsigned int length); should be even faster ? And string::length() simply returns an internal counter, and doesn't do a strlen() when called ? Starting to think about weird hacks: how about keeping the shared-data during string assignment as it is now but additionally keep a pointer to the eventually already allocated buffer around, so that it can be reused as soon as copy-on-write is required ? > Likewise, just look at the sources (we are on free software projects, > right? ;) /me feels like looking already at the sources of enough (both free and closed source) projects. > basically is the same as reserve + a fill of default-constructed chars on > the tail. You don't need the last part, right? Ok, so I'll use reserve() instead. Alex -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29037
