Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44299862.8060007@roguewave.com>
Date: Tue, 28 Mar 2006 13:11:14 -0700
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: test for lib.string.insert
References: <4D6A8407B7AC6F4D95B0E55C4E7C4C6203EEA6A4@exmsk.moscow.vdiweb.com>
In-Reply-To: 
 <4D6A8407B7AC6F4D95B0E55C4E7C4C6203EEA6A4@exmsk.moscow.vdiweb.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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 test?

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

Martin