stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Pevtsov <>
Subject Re: Re: test for lib.string.insert
Date Wed, 29 Mar 2006 15:10:37 GMT
The attached file contains new test version updated according your

I used different array here, but may be it will be useful to create
another one using bitmaps and compare these versions.

I found an issue in the rw_widen function implementation for chars: 
Suppose we have an array of chars needed to be widen. We know its
length, and this length doesn't include '\0' character (actually, _len
fields of TEstCases structure contain such values).
After call to rw_widen for wchar_t or UserChar we receive a "string"
with L'\0' or UseChar::eos at the end. But the rw_widen for chars
doesn't add the '\0' character.
So the result of using "rw_widened" char string become unpredictable if
the length is not specified (insert (pos, char* s) for example).

I corrected this by adding '\0' symbol to the end of the resulting array
(char.cpp, line 248)

            // copy src into dst
            memcpy (dst, src, len);
            dst [len] = '\0';

What do you think about it?

Also I split rw_assert's formatting parameters into three parts 
using rw_asnprintf function.

Current test version doesn't contain exception safety tests. I am
working on them.

Martin Sebor wrote:

>> I'm not sure about this. Isn't the TestCase struct different for each

It is possible to create test version containing all fields which may be
required by a test. But at the same time, we will get a group of these
fields as unused parameters for simple tests.
I think we can leave the TestCase structure as is and revisit it when a
significant amount of tests will be ready.

Martin Sebor wrote:

>> FYI: I may not be able to do much more than define the enums (if that)
until I get back from my trip on 4/17.


Anton Pevtsov

-----Original Message-----
From: Martin Sebor [] 
Sent: Wednesday, March 29, 2006 00:11
Subject: Re: test for lib.string.insert

Anton Pevtsov wrote:

>> OK, I'll update the tests on this way, starting with insert.
>> But may be it will be useful to split the test_cases array into 
>> several arrays of the TestCase structures. Each array will be used to 
>> exercise one set of methods with equivalent results. I thinks this 
>> allow us to avoid unnecessary ifs and each new array will be 
>> significantly less than universal test_cases array.

Sure, that sounds like a good idea to me.

>> On other hand we may form a bitmask from enum values (i.e. they will 
>> have values 1, 2, 4, etc), add an integer field to TestCase structure 
>> and use this value to indicate methods for which this test case make 
>> sense. (E.g. in each macro forming the set of the test cases we will 
>> write something like (insert_off_ptr | insert_off_str) to indicate 
>> that all these test cases should be used to exercise the corresponding

>> insert versions).

That's an interesting idea. My approach has been to use the values of
the TestCase members to indicate which function(s) each element of the
array should exercise. Often (although admittedly not always) the values
clearly preclude them from being used to exercise some functions. I
suppose having a bitmap explicitly indicating which functions should be
exercise might make it unambiguous. At the same time, a bitmap would
limit the number of functions to 32 unless we went with something more
sophisticated than a simple int.

>> In any case it may be useful to move TestCase structure into a test 
>> driver header file with enums and make it common for all string 
>> methods tests.

I'm not sure about this. Isn't the TestCase struct different for each

>> And I'll try to do something with monster rw_assert's.

Heh  :)  That will be great!

FYI: I may not be able to do much more than define the enums (if that)
until I get back from my trip on 4/17.


>>>>Another important area to exercise (so far we've been ignoring it) is
>> the exception safety of all these calls. I suggest you look at the
>> 23.vector.modifiers.cpp test to see how it's done there. We   > will
>> need to modify all the string tests to do something similar (although 
>> not as complicated since the charT ctors or assignment operator can't 
>> throw).
>> OK, I'll add exception safety tests. They are really important.

Yes. Initially we can throw the exception from the user-defined
allocator (for basic_string specializations other than std::string and
std::wstring) but please keep in mind that we will eventually need to
come up with a portable way to induce a bad_alloc exception even for
these containers.

My suggestion would be to start writing the tests in a way that doesn't
require that the exception be thrown on platforms where we don't know
how to induce it yet in order for the tests to pass. The tests should
detect the ability to induce an exception, issue a warning (via
rw_warn()) when they can't and avoid trying. When it is possible to
induce the exception the tests should then proceed to do so and verify
exception safety along the lines of the vector test. This approach will
hopefully make it easy to enable the exception safety tests as soon as
we figure out how to induce them even on the tricky platforms (AIX and


View raw message