stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: question about 25.for.each.cpp (was Re: Stdcxx test porting)
Date Tue, 22 Nov 2005 23:01:10 GMT
Anton Pevtsov wrote:
> 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 &'
> 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?

Yes, it is. Even though for_each is listed among non-modifying
algorithms it is explicitly allowed to modify the subject sequence
so long as the sequence is specified by mutable iterators (see LWG
issue 475). Since Input Iterators are not mutable (and according
to Table 72, the return type of operator*() is convertible to T,
not necessarily to T&) they cannot be used in invocations of
algorithms that modify its argument (or attempt to convert it
to anything other than T).

In fact, an even more strict implementation of operator*() would
return a type distinct from T that is convertible to T (e.g., a
private class that defines the conversion function operator T()).

What this means for the test is that the InputIter specialization
of the test function cannot use the std::negate function object.
Which is fine in any case since std::negate doesn't allow us to
sufficiently exercise the algorithm anyway (we should also keep
track of the number of invocations of the function object's
operator() and perhaps other attributes as well).

I enhanced the test to exercise Input Iterators as well as other
non-mutable iterators with a user-defined function object. See
Btw., while doing it I realized that generating the sequence is
probably adequate for this test and that changing it to hardcode
it instead may not actually be worth the trouble.


Here's a link to the LWG (Library Working Group) issue:

View raw message