stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Pevtsov <ant...@moscow.vdiweb.com>
Subject Re: RE: testing exception safety of string member templates (was: Re: lib.string.capacity test update)
Date Mon, 05 Jun 2006 15:04:58 GMT
Martin Sebor wrote:
[...]

>> 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.

Great! 
And thank you for the explanation.

Martin Sebor wrote:

> <>> 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.
>
Unfortunately, the gcc 4.0 fails to compile the changes you made. It
looks like the compiler could not choose which overload (with
String::pointer or String::iterator) to call when charT is simple char.
This results in the error "<function> cannot be overloaded".
I've played with it and finally decided to make the begin method virtual
and create three new template classes based on the ReplaceRangeOverload
template, one per each pair of const and non-const iterators. The file
with these changes is attached. May be there is some other (less
complicated) way to help the gcc to resolve the ambiguity with iterator
types. If so, I thnik we should switch to it, but verify that all
compilers accept it before.

Also I noticed that both versions produce 600 asserts on Windows. I'll
investigate their cause.

Thanks,
Anton Pevtsov

> <>-----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Saturday, June 03, 2006 06:33
> To: stdcxx-dev@incubator.apache.org
> Subject: testing exception safety of string member templates (was: Re:
> lib.string.capacity test update)
>
>
> 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


Mime
View raw message