This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: std::string::reserve()
Neil Ferguson wrote:
I'll have a word with my bosses and see what they think.
Ok, keep us updated.
I take your point, but I don't really understand what the leaked state
represents, or what one is supposed to do when it occurs. Can you tell
me more, or where to look, please?
Oh, well, this is an old interesting story: in short, without a leaked
state a refcounted string cannot be conforming (see 21.3). Consider:
string s("abc");
char& c(s[1]); <--- here s becomes leaked...
string t = s; <--- ... otherwise, here, s is refcopied...
c = 'z'; <--- ... and here we alter both s _and t_: argh!!
It does seem to me that previous versions of reserve() could return
with the string still in the leaked state, though, if the method
decided that no call to _M_clone() was necessary.
Indeed, but in that case you didn't pay the price of _S_create inside
_M_clone, so... probably a good trade-off: the string doesn't become
sharable but we don't spend time copying it either...
At first glance, the XPASS doesn't seem like it would be connected.
Indeed. Good.
Paolo.
P.S. Some changes may be risky even if the testsuite passes if you don't
fully understand the leaked state ;) ;)