testing exception safety of string member templates (was: Re: lib.string.capacity test update)

[Martin Sebor <se...@roguewave.com>]

Anton Pevtsov wrote:
[...]
> I think I caught your idea. Today I modified the replace test (see the 
> attached file, please) to
> exercise the exception safety for the range overload too,

Looks great! You should be able to change the type of the
ReplaceBase* argument to const ReplaceBase& and avoid the clunky
syntax when invoking its operator(). I.e., you should be able to
replace

     ret_ptr = &(*prb)(str, args...);

with just

     ret_ptr = &rb (str, args...);

Another simplification to consider (I'm not 100% sure it's a good
idea but I can't think of any problems with it either) is to change
the templates to take a String argument instead of all of charT,
Traits, and Allocator. I guess it doesn't matter which way we go
on this one.


> but got
> strange results.
> I found that the allocation for InputIterator occurs several times for
> long strings (it is ok, isn't it?).

Yes, it's (pretty much) inevitable.

> Consider the following test case:
> 
> TEST ("a@1000",    0,     0, "b@1000", 0, -1, "b@1000a@1000",     0),
> 
> Here the allocation takes place two times when we are using UserAlloc.
> Suppose that first allocation is ok, but the second one fails: the
> bad_alloc is thrown. It will be catched, and we will see that the string
> state was changed by the first reallocation. Is this correct from the
> exception safety standpoint?

That depends :) Strictly speaking it is unspecified. The result of
the replace member function template is described by a Returns clause
which places a requirement only on the return value of the function
but not on its effects (which is what the Effects clause is for).
While I don't think that's the intent of the text it is what the
standard currently in effect says. The intent, I believe, is as if
the Returns clause were an Effects clause, including the exception
safety implications. I.e., that an exception have no effects on the
state of the object.

In my opinion this level of exception safety is appropriate for all
specializations of the template *except* for InputIterators. Why?
Because there is no way to get back at elements once they've been
extracted from an input iterator (consider extracting elements from
std::cin, pipe or a socket). I don't believe that data loss is
an acceptable tradeoff for strong exception safety.

Anyway, the latest version of string (the one that've had checked
out for weeks while working on fixing STDCXX-170:
http://issues.apache.org/jira/browse/STDCXX-170) behaves as is
(intended to be) required by the standard, i.e., it doesn't
modify the object.

> If so, the test should be corrected. And of course, you might want make
> other comments and notes.

I've made some of the changes I mentioned above and then some
(see the attachment). Specifically, I added another class template
to let us more easily exercise (non-template) overloads of the range
members. I didn't commit the test because the code that's supposed
to exercise reverse_iterators is broken and commented out. Feel free
to make changes and improvements and post your version for review.

Martin