23.list.iterators test with environment

[Farid Zaripov <Fa...@kyiv.vdiweb.com>]

tests/include/23.list.h
tests/src/23.list.cpp
tests/containers/23.list.iterators.cpp

   This test (based on 21.string.iterators test) exercises the following 
list class methods: begin, end, rbegin, rend, front, back, get_allocator.


There are several notes:

   1. 23.list.* is based on 21.strings.* and adapted for the list. But 
it looks similar to strings, so I suugest to move the common code to 
separate files and reuse it in the containres and strings tests.

   2. Two types are used as list elements: POD (char) and NonPOD (struct 
X from alg_test.h). But for testing the char and X by the same way it is 
needed to adapt the functions from rw_char.h to the type X (rw_expand, 
rw_match, ...). I created the temporary functions rw_expand, rw_match 
for the type X (defined in 23.list.*). But the rw_match analogue for the 
type X is not completely conform to other rw_match'es - it cannot work 
with strings which contain "@" and requires expand. Are we needed in 
such strings in the container's tests?.
Also maybe it will be useful to add the method X::to_char () (like 
UserChar::to_char ()). Currently the test uses the static function 
to_char defined in 23.list.h.

   3. ListTestCase was expanded from the StringTestCase structure by 
adding additional members (functors Predicate, BinaryPredicate, Compare) 
for the methods remove_if, unique, merge, sort. I think it should be 
enough to define these members as a pointer to a function to leave 
ListTestCase non-template. ListTestCaseData<T> contains the functors 
pred_, bpred_, comp_ to be passed to the methods mentioned above. These 
functors use the pointer corresponding to the function from ListTestCase.

   4. ListStateT currently cannot be used in tests modifying the list 
object. I think ListStateT::assert_equal should have an additional 
argument of type ListTestCaseData to detect which iterators and 
references should be changed by the test to not compare them.

Farid.

Re: 23.list.iterators test with environment

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

Martin Sebor wrote:
> Farid Zaripov wrote:
[...]
>>   3. ListTestCase was expanded from the StringTestCase structure by 
>> adding additional members (functors Predicate, BinaryPredicate, 
>> Compare) for the methods remove_if, unique, merge, sort. I think it 
>> should be enough to define these members as a pointer to a function to 
>> leave ListTestCase non-template.
> 
> 
> I agree with not parameterizing the base class but I suspect that
> simple function pointers aren't going to do it. The predicate
> functions need to take the actual objects as arguments, not just
> chars. In addition, storing three pointers when only one per test
> case (or maybe one per test?) is needed seems wasteful. Would
> something like the rough sketch below work?

Actually, I think we should be able to do something even simpler
than that. Assuming there will only be a small set of predicates
(say four) we will want to use in these tests, we can simply add
a integer data member to the ContainerTestCase struct to allow
us to pick the one to be used with each test case.

Martin

Re: 23.list.iterators test with environment

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

Farid Zaripov wrote:
> tests/include/23.list.h
> tests/src/23.list.cpp
> tests/containers/23.list.iterators.cpp
> 
>   This test (based on 21.string.iterators test) exercises the following 
> list class methods: begin, end, rbegin, rend, front, back, get_allocator.

Okay, this looks like a good start! One goal of the painstaking
iterative refinements we've been making to the string tests and
the driver has been to be able to reuse at least the same approach
if not much of the same code in the containers tests. It looks like
it might be starting to pay off.

> 
> 
> There are several notes:
> 
>   1. 23.list.* is based on 21.strings.* and adapted for the list. But it 
> looks similar to strings, so I suugest to move the common code to 
> separate files and reuse it in the containres and strings tests.

Agreed. I expect we'll end up with the equivalent of 21.string.*
for containers, i.e., 23.containers.h and 23.containers.cpp. It
might even be that 21.string.h will end up being implemented in
terms of 23.containers.cpp.

> 
>   2. Two types are used as list elements: POD (char) and NonPOD (struct 
> X from alg_test.h). But for testing the char and X by the same way it is 
> needed to adapt the functions from rw_char.h to the type X (rw_expand, 
> rw_match, ...).

Excellent point! We need to exercise containers other than string
with both kinds of types.

> I created the temporary functions rw_expand, rw_match 
> for the type X (defined in 23.list.*).

I haven't looked at it very carefully yet but I'm hoping that we'll
be able to have a single 23.containers.{h,cpp} rather than a set of
headers and sources, one for each container.

> But the rw_match analogue for the 
> type X is not completely conform to other rw_match'es - it cannot work 
> with strings which contain "@" and requires expand. Are we needed in 
> such strings in the container's tests?.

You mean "do we need to be able to expand strings containing the
<char>@<count> directives into very large arrays of X? I assume
so. How else would we create such arrays?

> Also maybe it will be useful to add the method X::to_char () (like 
> UserChar::to_char ()).

There's UserInt::to_char() but I don't see a UserChar::to_char().
What would the function be good for? (All X data members are
publicly accessible.)

> Currently the test uses the static function 
> to_char defined in 23.list.h.
> 
>   3. ListTestCase was expanded from the StringTestCase structure by 
> adding additional members (functors Predicate, BinaryPredicate, Compare) 
> for the methods remove_if, unique, merge, sort. I think it should be 
> enough to define these members as a pointer to a function to leave 
> ListTestCase non-template.

I agree with not parameterizing the base class but I suspect that
simple function pointers aren't going to do it. The predicate
functions need to take the actual objects as arguments, not just
chars. In addition, storing three pointers when only one per test
case (or maybe one per test?) is needed seems wasteful. Would
something like the rough sketch below work?

   struct PredicateBase {
       virtual bool operator()(char);
       virtual bool operator()(char, char);
       virtual bool operator()(const X&);
       virtual bool operator()(const X&, const X&);
   };

   struct ContainerTestCase {
       PredicateBase *pred;
       // ...other members...
   };

   struct Less: PredicateBase { /* ... */ } pred_less;
   struct Greater: PredicateBase { /* ... */ } pred_greater;

   ListTestCase remove_if_tests[] = {
       // predicate,  initial   predicate  expected
       //             sequence  argument   result
       &pred_less,    "abcdef", 'd',       "def",
       &pred_greater, "abcdef", 'c',       "abc",
       // ...
   };

>   4. ListStateT currently cannot be used in tests modifying the list 
> object. I think ListStateT::assert_equal should have an additional 
> argument of type ListTestCaseData to detect which iterators and 
> references should be changed by the test to not compare them.

I'm afraid I'm out of time again to comment on this. Let me get
back to this question and this whole test tomorrow.

Martin