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: test for lib.alg.remove
Date Tue, 20 Dec 2005 20:31:27 GMT
Anton Pevtsov wrote:
> The attached file contains my attempt to update lib.alg.remove test and
> port it to new test driver.

Great, thanks! I will commit it shortly.

> 
> Here I implemented the helper class ToString to be used instead of 
> tempstr and to_string to convert a range of X objects to a string.
> 
> I think it may be useful for other tests.

That was the original idea behind the to_string() helper but I'm
not sure its output is very clear.

The point of the function was to help with the debugging of the
library as well as the tests themselves. The problem with it is
that the output it produces tends to be confusing, especially
when coupled with the simple character string used to represent
the input to the algorithms.

Consider this output, for instance (obtained by running the test
with the --trace command line argument):

# ITRACE_ASSERTION (S0) (3 lines):
# TEXT: line 262: remove<ForwardIterator>("abc", ..., 'a') ==>
98, 99, >99< ; expected element value 99
# LINE: 464

The input sequence is pretty clear ("abc"). The output sequence,
OTOH, is less clear: "98, 99, >99<" It's not immediately obvious
that 98 is the ASCII value of 'b'. It's also not obvious what the
ticks around 99 mean (in a failed assertion they would surround
the mismatched element).

Would something like this be better?

   remove<ForwardIterator>("abc", ..., 'a') ==>
   "bc>c<"; expected element value: 'c'.

Now, consider this more involved output:

# ITRACE_ASSERTION (S0) (3 lines):
# TEXT: line 279: remove<ForwardIterator>("aba", ..., 'a') => >90:98<, 
91:98, 92:97 unstable: incorrect elements order at 0 position elements 
ids: 90 and 91
# LINE: 467

Can you tell what all the pairs of numbers separated by colons mean?
I can because I wrote the formatting function and you now can as well
because you reimplemented it, but I'll bet no one else would be able
to. (They denote a <id>:<value> pair of each element in the resulting
sequence, with each <id> being unique among all objects of the type
in a program; knowing the id is important in determining the positions
of copies of the moved elements).

I'm not sure what would be a better format in this case, though.
Any ideas?

Martin

Mime
View raw message