This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/22634] partial_sum is too constrained
- From: "gdr at integrable-solutions dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 24 Jul 2005 03:27:26 -0000
- Subject: [Bug libstdc++/22634] partial_sum is too constrained
- References: <20050723200746.22634.squell@alumina.nl>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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" <gcc-bugzilla@gcc.gnu.org> 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