tmp/tmp8jwave50/{from.md → to.md}
RENAMED
|
@@ -17,16 +17,16 @@ argument is modified. — *end note*]
|
|
| 17 |
Unless otherwise stated, implementations may make arbitrary copies of
|
| 18 |
elements (with type `T`) from sequences where
|
| 19 |
`is_trivially_copy_constructible_v<T>` and
|
| 20 |
`is_trivially_destructible_v<T>` are `true`.
|
| 21 |
|
| 22 |
-
[*Note 2*: This implies that user-supplied function objects
|
| 23 |
-
|
| 24 |
-
|
| 25 |
-
|
| 26 |
-
|
| 27 |
-
|
| 28 |
|
| 29 |
The invocations of element access functions in parallel algorithms
|
| 30 |
invoked with an execution policy object of type
|
| 31 |
`execution::sequenced_policy` all occur in the calling thread of
|
| 32 |
execution.
|
|
@@ -38,18 +38,18 @@ The invocations of element access functions in parallel algorithms
|
|
| 38 |
invoked with an execution policy object of type
|
| 39 |
`execution::unsequenced_policy` are permitted to execute in an unordered
|
| 40 |
fashion in the calling thread of execution, unsequenced with respect to
|
| 41 |
one another in the calling thread of execution.
|
| 42 |
|
| 43 |
-
[*Note 4*: This means that multiple function object invocations
|
| 44 |
interleaved on a single thread of execution, which overrides the usual
|
| 45 |
guarantee from [[intro.execution]] that function executions do not
|
| 46 |
overlap with one another. — *end note*]
|
| 47 |
|
| 48 |
The behavior of a program is undefined if it invokes a
|
| 49 |
vectorization-unsafe standard library function from user code called
|
| 50 |
-
from
|
| 51 |
|
| 52 |
[*Note 5*: Because `execution::unsequenced_policy` allows the execution
|
| 53 |
of element access functions to be interleaved on a single thread of
|
| 54 |
execution, blocking synchronization, including the use of mutexes, risks
|
| 55 |
deadlock. — *end note*]
|
|
@@ -128,18 +128,18 @@ unordered fashion in unspecified threads of execution, and unsequenced
|
|
| 128 |
with respect to one another within each thread of execution. These
|
| 129 |
threads of execution are either the invoking thread of execution or
|
| 130 |
threads of execution implicitly created by the library; the latter will
|
| 131 |
provide weakly parallel forward progress guarantees.
|
| 132 |
|
| 133 |
-
[*Note 7*: This means that multiple function object invocations
|
| 134 |
interleaved on a single thread of execution, which overrides the usual
|
| 135 |
guarantee from [[intro.execution]] that function executions do not
|
| 136 |
overlap with one another. — *end note*]
|
| 137 |
|
| 138 |
The behavior of a program is undefined if it invokes a
|
| 139 |
vectorization-unsafe standard library function from user code called
|
| 140 |
-
from
|
| 141 |
|
| 142 |
[*Note 8*: Because `execution::parallel_unsequenced_policy` allows the
|
| 143 |
execution of element access functions to be interleaved on a single
|
| 144 |
thread of execution, blocking synchronization, including the use of
|
| 145 |
mutexes, risks deadlock. — *end note*]
|
|
|
|
| 17 |
Unless otherwise stated, implementations may make arbitrary copies of
|
| 18 |
elements (with type `T`) from sequences where
|
| 19 |
`is_trivially_copy_constructible_v<T>` and
|
| 20 |
`is_trivially_destructible_v<T>` are `true`.
|
| 21 |
|
| 22 |
+
[*Note 2*: This implies that user-supplied function objects cannot rely
|
| 23 |
+
on object identity of arguments for such input sequences. If object
|
| 24 |
+
identity of the arguments to these function objects is important, a
|
| 25 |
+
wrapping iterator that returns a non-copied implementation object such
|
| 26 |
+
as `reference_wrapper<T>` [[refwrap]], or some equivalent solution, can
|
| 27 |
+
be used. — *end note*]
|
| 28 |
|
| 29 |
The invocations of element access functions in parallel algorithms
|
| 30 |
invoked with an execution policy object of type
|
| 31 |
`execution::sequenced_policy` all occur in the calling thread of
|
| 32 |
execution.
|
|
|
|
| 38 |
invoked with an execution policy object of type
|
| 39 |
`execution::unsequenced_policy` are permitted to execute in an unordered
|
| 40 |
fashion in the calling thread of execution, unsequenced with respect to
|
| 41 |
one another in the calling thread of execution.
|
| 42 |
|
| 43 |
+
[*Note 4*: This means that multiple function object invocations can be
|
| 44 |
interleaved on a single thread of execution, which overrides the usual
|
| 45 |
guarantee from [[intro.execution]] that function executions do not
|
| 46 |
overlap with one another. — *end note*]
|
| 47 |
|
| 48 |
The behavior of a program is undefined if it invokes a
|
| 49 |
vectorization-unsafe standard library function from user code called
|
| 50 |
+
from an `execution::unsequenced_policy` algorithm.
|
| 51 |
|
| 52 |
[*Note 5*: Because `execution::unsequenced_policy` allows the execution
|
| 53 |
of element access functions to be interleaved on a single thread of
|
| 54 |
execution, blocking synchronization, including the use of mutexes, risks
|
| 55 |
deadlock. — *end note*]
|
|
|
|
| 128 |
with respect to one another within each thread of execution. These
|
| 129 |
threads of execution are either the invoking thread of execution or
|
| 130 |
threads of execution implicitly created by the library; the latter will
|
| 131 |
provide weakly parallel forward progress guarantees.
|
| 132 |
|
| 133 |
+
[*Note 7*: This means that multiple function object invocations can be
|
| 134 |
interleaved on a single thread of execution, which overrides the usual
|
| 135 |
guarantee from [[intro.execution]] that function executions do not
|
| 136 |
overlap with one another. — *end note*]
|
| 137 |
|
| 138 |
The behavior of a program is undefined if it invokes a
|
| 139 |
vectorization-unsafe standard library function from user code called
|
| 140 |
+
from an `execution::parallel_unsequenced_policy` algorithm.
|
| 141 |
|
| 142 |
[*Note 8*: Because `execution::parallel_unsequenced_policy` allows the
|
| 143 |
execution of element access functions to be interleaved on a single
|
| 144 |
thread of execution, blocking synchronization, including the use of
|
| 145 |
mutexes, risks deadlock. — *end note*]
|