incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Pevtsov" <Ant...@moscow.vdiweb.com>
Subject RE: question about 25.for.each.cpp (was Re: Stdcxx test porting)
Date Tue, 22 Nov 2005 16:59:09 GMT
Martin Sebor wrote:
> Yes, we should, eventually. Good catch!

I tried to insert the test for InputIterator to the for_each algorithm
tests but faced with the following problem:

error C2664: 
'void std::negate<X>::operator
()(std::unary_function<_Arg,_Result>::argument_type &)' : 
cannot convert parameter 1 from 
'const InputIter<T>::value_type' to 
'std::unary_function<_Arg,_Result>::argument_type &'
        with
        [
            _Arg=X,
            _Result=X
        ]
        and
        [
            T=X
        ]
        and
        [
            _Arg=X,
            _Result=X
        ]

I suspect that cause of this problem is that class InputIter used for
the tests returns const value_type& from its operator * (). There is a
reason for this behaviour (from alg_test.h)

    // returning const-reference rather than a value in order
    // not to impose the CopyConstructible requirement on T
    // and to disallow constructs like *InputIter<T>() = T()

But is this behaviour of  InputIter::operator * correct?

Martin Sebor wrote:
> For instance, the for.each test isn't quite as exhaustive as it should
be (the function object isn't being sufficiently exercised), nor does it
readily lend itself to being enhanced to be (ditto for the    > equal
test). I think the adjacent.find test is structured much better (with
one test case per line) and would eventually like to rewrite the other
tests along the same lines.

Does this mean that you would like to specify the test sequences
manually (as in adjacent.find test) instead of its automatic generation?


With best wishes,
Anton Pevtsov

-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Monday, November 21, 2005 21:00
To: stdcxx-dev@incubator.apache.org
Subject: question about 25.for.each.cpp (was Re: Stdcxx test porting)


Anton Pevtsov wrote:
> Martin,
[...]
> Btw, I have a question about the for_each algorithm test. Shall we 
> test this algorithm in additional with InputIterator? Actually we test

> it with Forward, Bidirectional and Random Access iterators, but as far

> as I know the for_each algorithm requires InputIterator.

Yes, we should, eventually. Good catch!

I'm fine with you just porting the test as they are, or with enhancing
them at the same as we're discussing. I think doing both in one go might
be less time-consuming than porting them first and then coming back to
them and enhancing them.

In addition, while you're doing the porting I would encourage you to
think about how to improve and simplify the tests even further.

For instance, the for.each test isn't quite as exhaustive as it should
be (the function object isn't being sufficiently exercised), nor does it
readily lend itself to being enhanced to be (ditto for the equal test).
I think the adjacent.find test is structured much better (with one test
case per line) and would eventually like to rewrite the other tests
along the same lines.

Another example of where the tests could be improved is the amount of
boilerplate code required to set them up (the run_tests function and all
the invocations of the specializations of the test function). It would
be nice to reduce this overhead by getting the test driver to do all of
this work and have the test just provide the data (i.e., the addresses
of the functions and the names of the command line arguments to
enable/disable them).

Martin

Mime
View raw message