------- Additional Comments From gdr at integrable-solutions dot net 2005-07-24 17:18 ------- Subject: Re: partial_sum is too constrained
"squell at alumina dot nl" <[EMAIL PROTECTED]> writes: | ------- Additional Comments From squell at alumina dot nl 2005-07-24 16:42 ------- | (In reply to comment #7) | | > 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. | | Yes, I noticed the standard isn't explicit about that, Oh, the standard is quite explicit about that. Look up the requirement table input iterators and compare it with other iterators. | but isn't | that requirement implied in the semantics for '*r++'? No. | I read somewhere the LWG believed the requirement to be implicit. | (found: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241) No, that is issue is different. I'm talking about the copy-construction of the iterator itself; you're talking about the copy-construction of the value_type. Not the same thing. | > 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. | | I agree the paragraph should probably make it explicit what type is being | used. I think there's another subtle error in the Effects clause, since | dereferencing an input iterator invalidates previous copies, and order of | evaluation is unspecified. | | I noticed this also happens in unique_copy. It works on Input Iterators but | its semantics are specified in terms of '*i == *(i-1)' or 'pred(*i, *(i-1))'. | | Perhaps this should be part of the DR, or a seperate one? It should probably be a separate one. Thanks! -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
