------- Additional Comments From gdr at integrable-solutions dot net 2005-07-24 03:27 ------- Subject: Re: partial_sum is too constrained
"squell at alumina dot nl" <[EMAIL PROTECTED]> writes: | (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 :) Indeed. | 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'. Yes, the standard requirements for iterators exhibit inconsistencies at many places; for example an InputIterator is not required (by the Standard) to be copy-constructible; consequently it cannot be used as function parameter type. Which means that things like copy(), accumulate() and friends are not supposed to work. Yes, obviously that is a bug in the standard. We've found a few of them recently. BAck to the issue of this PR; I think there is way too vagueness in the standard and the "obvious" thing to do is to use the natural type of the intermediate results. However, we may actually want to submit a DR (I'll do it). I would suggest this issue be suspended in the meantime. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
