Topic: Defect Report: partial_sum and adjacent_difference should mention
Author: squell@alumina.nl (Marc Schoolderman)
Date: Tue, 7 Feb 2006 17:30:10 GMT Raw View
kuyper@wizard.net wrote:
> The wording, as written, seems to require that it behave as if the
> accumulator had the same type as the value returned by *i + *(i+1)
> binary_op(*i,*(i-1)). That's not necessarily the same type as either
> the input iterator's value type, or the output iterator's value type.
> Without typeof(), I think it would be rather tricky to achieve that.
It can be implemented by using a secondary function template accepting
the result of the first operation; somewhat similar to how many
functions are overloaded on xx_iterator_tag's or other types.
The addition of typeof() or 'auto' would make it trivial, of course.
> To make things worse, consider the case where *i+*(i+1) has a different
> type than (*i+(*i+1))+*(i+2), or similarly for binary_op(). Thanks to
> function and operator overloading, it's quite feasible for that to be
> the case. I'm not sure it's actually feasible to correctly implement
> partial_sum() for such a class.
Indeed. By analogy to accumulate(), a reasonable expectation would then
be that the type of (*i+(*i+1))+*(i+2) should be identical to the type
of *i+*(i+1).
Another reasonable expectation would be that + or binary_op describe a
commutative operation, i.e. (*i+(*i+1))+*(i+2) == *i+((*i+1)+*(i+2)),
since this function is supposed to be numeric in nature.
These additional issues apply to both implementation options; I think
right now, the intended functionality of partial_sum is a more important
question anyway.
~Marc.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]