This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 26.7.4 [alg.transform] Status: NAD Submitter: Angelika Langer Opened: 2001-01-04 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [alg.transform].
View all issues with NAD status.
Discussion:
This issue is related to issue 242. In case that the resolution proposed for issue 242 is accepted, we have have the following situation: The 4 numeric algorithms (accumulate and consorts) as well as transform would allow a certain category of side effects. The numeric algorithms specify that they invoke the functor "for every iterator i in the range [first, last) in order". transform, in contrast, would not give any guarantee regarding order of invocation of the functor, which means that the functor can be invoked in any arbitrary order.
Why would that be a problem? Consider an example: say the transformator that is a simple enumerator ( or more generally speaking, "is order-sensitive" ). Since a standard compliant implementation of transform is free to invoke the enumerator in no definite order, the result could be a garbled enumeration. Strictly speaking this is not a problem, but it is certainly at odds with the prevalent understanding of transform as an algorithms that assigns "a new _corresponding_ value" to the output elements.
All implementations that I know of invoke the transformator in definite order, namely starting from first and proceeding to last - 1. Unless there is an optimization conceivable that takes advantage of the indefinite order I would suggest to specify the order, because it eliminate the uncertainty that users would otherwise have regarding the order of execution of their potentially order-sensitive function objects.
Proposed resolution:
In section 25.2.3 - Transform [lib.alg.transform] change:
-1- Effects: Assigns through every iterator i in the range [result, result + (last1 - first1)) a new corresponding value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + (i - result), *(first2 + (i - result))).
to:
-1- Effects: Computes values by invoking the operation op or binary_op for every iterator in the range [first1, last1) in order. Assigns through every iterator i in the range [result, result + (last1 - first1)) a new corresponding value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + (i - result), *(first2 + (i - result))).
Rationale:
For Input Iterators an order is already guaranteed, because only one order is possible. If a user who passes a Forward Iterator to one of these algorithms really needs a specific order of execution, it's possible to achieve that effect by wrapping it in an Input Iterator adaptor.