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: lib.string.capacity test update
Date Fri, 02 Jun 2006 16:08:46 GMT
Martin Sebor wrote:

>> I spent today looking at this and trying some changes. 
>  
>
[...]

> <>> Until the question of exactly what is required is resolved I think it

> <>will be best to put this on hold and finish the rest of the string
> tests. If it turns out that the only allocator members that are >
> required to be called really are allocate and deallocate it will
> simplify > the checking quite a bit.
>
Ok.<>
Martin Sebor wrote:

> <>>I'm not sure exactly what other string tests are left but 
> anenhancement that still needs to be implemented across several of the

> <>tests (ctors, append, erase, insert and replace) is exercising the

>>exception safety of the member function templates.
>  
>

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, but got
strange results.
I found that the allocation for InputIterator occurs several times for
long strings (it is ok, isn't it?).
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?
If so, the test should be corrected. And of course, you might want make
other comments and notes.

I plan to verify this kind of the exception safety on another STL
implementation using our UserAlloc.

Thanks, 
Anton Pevtsov


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Friday, June 02, 2006 03:37
To: stdcxx-dev@incubator.apache.org
Subject: Re: lib.string.capacity test update

I spent today looking at this and trying some changes. I still think
it's a good approach in principle but I'm finding out that containers in
general and strings in particular don't seem to be required to use any
allocator functions other than allocate and deallocate. That makes the
tests not just difficult to write with any accuracy but also rather
pointless. I posted a question to the committee's mailing list to see
what the intent is (it's possible that the requirement is intended but
missing).


>> 
>> I think that on next steps of simplification we may bind this new 
>> structure with method overload id (there is a dependency between 
>> information stored in the structure and this id) and as a result 
>> verify the allocator usage in the same way as we done with "usual" 
>> test cases. What do you think about this?
>  
>

Until the question of exactly what is required is resolved I think it
will be best to put this on hold and finish the rest of the string
tests. If it turns out that the only allocator members that are required
to be called really are allocate and deallocate it will simplify the
checking quite a bit.

Btw., I'm not sure exactly what other string tests are left but an
enhancement that still needs to be implemented across several of the
tests (ctors, append, erase, insert and replace) is exercising the
exception safety of the member function templates. Since much of the
exception safety code in the range test functions will be the same as
the code in the functions testing the ordinary (non-template) overloads
it would be good to share it to avoid bloat and reduce maintenance
effort.

Martin


Mime
View raw message