------- Additional Comments From squell at alumina dot nl 2005-07-23 23:20
-------
(In reply to comment #2)
> ((...(*first + *(first + 1)) + ...) + *(first + (i - result)))
> So arithmetic is done with the data type of the input range. That may be
> undesirable on occasion, but that's what the standard says.
The standard is too vague on this routine to say such things, which rather is
the problem :)
About the only thing we know is that this routine takes Input Iterators.
Those have the requirements that '*i' is "convertible to T". The standard
doesn't specify what an operator+ (or binary_op) that is used should look
like. It especially doesn't say it takes arguments of value_type and outputs
a result of value_type.
It does explicitly say that the value_type of an input iterator is not
required to be assignable (see 24.1.1/3), which anyway means the present
implementation isn't strictly conforming since it uses 'value = value + *first'.
My proposal fixes this (quite trivially), while introducing any runtime
inefficiencies.
If the changed behaviour with expanding types is deemed too dangerous
because it introduces a change, the routine can be modified so it produces
identical results as the current partial_sum, by adding explicit type
conversions back to the input iterators value_type. That will at least
solve the problem of assigning to an Input Iterator's value_type.
I will not reopen this bug, but I suggest giving this some more thought.
~Marc.
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|enhancement |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
