incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: 23.list.iterators test with environment
Date Fri, 07 Jul 2006 02:02:56 GMT
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

Mime
View raw message