teratail
回答率
85.47%
質問するログイン新規登録
トップC++に関する質問C++ - std::for_each_n() が導入された理由について

編集履歴

回答編集履歴

5

refinement

2021/01/19 08:28

投稿

yohhoy
yohhoy

スコア6191

test CHANGED
@@ -6,11 +6,11 @@
6
6
 
7
7
 
8
8
 
9
- 第1引数に [実行ポリシー`ExecutionPolicy`](https://cpprefjp.github.io/reference/execution/execution/execution_policy.html) をとるマルチスレッド並列処理に非ランダムイテレータ（ForwardIteratorやBidirectionalIterator）を指定するケースでは、[`std::for_each`](https://cpprefjp.github.io/reference/algorithm/for_each.html)よりも[`std::for_each_n`](https://cpprefjp.github.io/reference/algorithm/for_each_n.html)の方が効率的に処理を実行できる可能性があります。
9
+ 第1引数に [実行ポリシー`ExecutionPolicy`](https://cpprefjp.github.io/reference/execution/execution/execution_policy.html) をとるマルチスレッド並列処理に非ランダムアクセスイテレータ（[前方向イテレータや双方向イテレータ](https://cpprefjp.github.io/reference/iterator.html)）を指定するケースでは、[`std::for_each`関数](https://cpprefjp.github.io/reference/algorithm/for_each.html) よりも [`std::for_each_n`関数](https://cpprefjp.github.io/reference/algorithm/for_each_n.html) の方が効率的に処理を実行できる可能性があります。
10
10
 
11
11
 
12
12
 
13
- `std::for_each`走査対象範囲を複数スレッドにチャンク分割するとき、「要素総数の計算」が [ランダムイテレータでは計算量 __O(1)__](https://cpprefjp.github.io/reference/iterator/distance.html) で済みますが、非ランダムイテレータでは計算量 __O(N)__ を必要とします。`std::for_each_n`ならばこの計算が必要ありません。
13
+ `std::for_each`走査対象範囲を複数スレッドにチャンク分割するとき、「要素総数の計算」が [ランダムアクセスイテレータでは計算量 __O(1)__](https://cpprefjp.github.io/reference/iterator/distance.html) で済みますが、非ランダムアクセスイテレータでは計算量 __O(N)__ を必要とします。`std::for_each_n`ならばこの計算が必要ありません。
14
14
 
15
15
 
16
16
 

4

add links

2021/01/19 08:28

投稿

yohhoy
yohhoy

スコア6191

test CHANGED
@@ -6,11 +6,11 @@
6
6
 
7
7
 
8
8
 
9
- 第1引数に [実行ポリシー`ExecutionPolicy`](https://cpprefjp.github.io/reference/execution/execution/execution_policy.html) をとるマルチスレッド並列処理に非ランダムイテレータ（ForwardIteratorやBidirectionalIterator）を指定するケースでは、`std::for_each`よりも`std::for_each_n` の方が効率的に処理を実行できる可能性があります。
9
+ 第1引数に [実行ポリシー`ExecutionPolicy`](https://cpprefjp.github.io/reference/execution/execution/execution_policy.html) をとるマルチスレッド並列処理に非ランダムイテレータ（ForwardIteratorやBidirectionalIterator）を指定するケースでは、[`std::for_each`](https://cpprefjp.github.io/reference/algorithm/for_each.html)よりも[`std::for_each_n`](https://cpprefjp.github.io/reference/algorithm/for_each_n.html)の方が効率的に処理を実行できる可能性があります。
10
10
 
11
11
 
12
12
 
13
- `std::for_each`走査対象範囲を複数スレッドにチャンク分割するとき、「要素総数の計算」がランダムイテレータでは計算量 __O(1)__ で済みますが、非ランダムイテレータでは計算量 __O(N)__ を必要とします。`std::for_each_n`ならばこの計算が必要ありません。
13
+ `std::for_each`走査対象範囲を複数スレッドにチャンク分割するとき、「要素総数の計算」が [ランダムイテレータでは計算量 __O(1)__](https://cpprefjp.github.io/reference/iterator/distance.html) で済みますが、非ランダムイテレータでは計算量 __O(N)__ を必要とします。`std::for_each_n`ならばこの計算が必要ありません。
14
14
 
15
15
 
16
16
 

3

refinement

2021/01/19 07:51

投稿

yohhoy
yohhoy

スコア6191

test CHANGED
@@ -2,11 +2,11 @@
2
2
 
3
3
 
4
4
 
5
- 通常の逐次処理（シングルスレッド処理）では、使い分けについて気にする必要はありません。その文脈において自然な方（イテレータペア指定 or 個数指定）を使えばよいでしょう。
5
+ 通常のシングルスレッド逐次処理では、使い分けについて気にする必要はありません。その文脈において自然な方（イテレータペア指定 or 個数指定）を使えばよいでしょう。
6
6
 
7
7
 
8
8
 
9
- 第1引数に [実行ポリシー`ExecutionPolicy`](https://cpprefjp.github.io/reference/execution/execution/execution_policy.html) をとる並列処理（マルチスレッド処理）に非ランダムイテレータ（ForwardIteratorやBidirectionalIterator）を指定するケースでは、`std::for_each`よりも`std::for_each_n` の方が効率的に処理を実行できる可能性があります。
9
+ 第1引数に [実行ポリシー`ExecutionPolicy`](https://cpprefjp.github.io/reference/execution/execution/execution_policy.html) をとるマルチスレッド並列処理に非ランダムイテレータ（ForwardIteratorやBidirectionalIterator）を指定するケースでは、`std::for_each`よりも`std::for_each_n` の方が効率的に処理を実行できる可能性があります。
10
10
 
11
11
 
12
12
 

2

fix layout

2021/01/19 07:21

投稿

yohhoy
yohhoy

スコア6191

test CHANGED
@@ -19,6 +19,8 @@
19
19
  ---
20
20
 
21
21
  > なぜ別の関数として追加されたのでしょうか。
22
+
23
+
22
24
 
23
25
  `std::for_each_n`は、C++17標準ライブラリに追加された「並列アルゴリズム」の一部として追加されました。
24
26
 

1

refinement

2021/01/19 07:20

投稿

yohhoy
yohhoy

スコア6191

test CHANGED
@@ -36,10 +36,10 @@
36
36
 
37
37
  > `std::for_each` assumes the function object it receives contains state which will be mutated inside a serial loop. It returns a copy of this state as a result. `std::for_each_n` does not exist.
38
38
 
39
- >
39
+ >
40
40
 
41
41
  > By contrast, `thrust::for_each` and `thrust::for_each_n` instantiate many copies of their function object parameter in parallel. In such a setting, shared mutable state within the function object is a performance hazard at best. At worst, it is impossible for some parallel substrates to achieve. Instead, `thrust::for_each` and `thrust::for_each_n` exist exclusively for the sake of the side effects they may induce on the elements of their input ranges.
42
42
 
43
- >
43
+ >
44
44
 
45
45
  > For consistency with other higher-level algorithms, `thrust::for_each` and `thrust::for_each_n` return the end of their input range. This simplifies the implementation of algorithms such as `thrust::generate_n` which can be lowered onto `thrust::for_each_n` in a straightforward manner.