Re: std::string::reserve()

[Neil Ferguson <nferguso at eso dot org>]

Paolo Carlini wrote:
>
> 1- If you plan contributing patches of this size you definitely need a
>   copyright assignment on file:
>
>     http://gcc.gnu.org/contribute.html

I hadn't thought that far ahead, to be honest.

I'll have a word with my bosses and see what they think.

> > 2- Your change definitely makes sense but not calling _M_clone has
> >   a not-completely-obvious effect: if the string is in the leaked
> >   state it remains leaked, doesn't become sharable. Perhaps you
> >   want to return early only if the string is already sharable?
>
> ... or, much better, simply remember to call _M_rep()->_M_set_sharable()
> before returning, since reserve is supposed to invalidate pointers,
> iterators, references anyway.

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?

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.

> 3- Please, please strive to have a working regtesting setup. It's
>   important not only to spare us the task (that's not a big deal)
>   but also when fixing bugs or envisaging large scale changes...

I should have gone home earlier last night - I was running the test
harness from the wrong shell...

Results as follows:

Running <snip> .../libstdc++-v3/testsuite/libstdc++-dg/normal.exp ...
XPASS: 26_numerics/c99_classification_macros_c.cc (test for excess errors)

                === libstdc++ Summary ===

# of expected passes            2558
# of unexpected successes       1
# of expected failures          2
make[3]: *** [check-DEJAGNU] Error 1

At first glance, the XPASS doesn't seem like it would be connected.

I wish I'd made a copy of the clean code from CVS, before I started
playing with it. *Now* it occurs to me. Typical :-)

Neil.