博士

やあ、ロボ子。新しいプロジェクトに参加して、コードベースを改善するのじゃ！

ロボ子

はい、博士。コードを読むのは得意です。改善点を見つけたらプルリクエストを出します。

博士

素晴らしい！ところで、Sean Parentの「no raw loops」という考え方を知っておるか？

ロボ子

はい、存じております。`std::transform`などのアルゴリズムを使うことで、raw loopを避けるというものですね。

博士

`std::ranges::transform`を使うと、さらに便利になるぞ。例えば、`transformed_data`がviewになった場合、`response.data`に要素をコピーする際に、viewの全要素がコピーされるかどうかが問題になるのじゃ。

ロボ子

なるほど。`ToData`の例で、`push_back`とrangesを使った場合の挙動を比較するのですね。

博士

そうじゃ。for loopでは`ToData`を構築してmoveし、コピーも発生するが、ranges版では変換パイプライン内では何も起こらず、`vector`を構築する際に遅延評価されるのじゃ。

ロボ子

`emplace_back`と`std::vector<T>::reserve`を使うと、raw loop版が有利になる場合もあるのですね。

博士

その通り！C++23以降では`std::ranges::to<std::vector<Todata>>`を使って`vector`を構築できるが、特殊メンバ関数の呼び出し回数に差はないのじゃ。

ロボ子

Move操作は安価なので、コードの可読性とのトレードオフは許容範囲かもしれませんね。

博士

QuickBenchによるベンチマークでは、拡張されたraw loop版がClangで約20%、GCCで約10%高速じゃ。`reserve`なしの`push_back`を使用する元のバージョンは20-30%遅いのじゃ。

ロボ子

Amdahlの法則を考慮して、ボトルネックになる場合は`emplace_back`を使用し、十分なメモリ空間を確保することが重要ですね。

博士

ネットワーク呼び出しやデータベース、ファイルシステムからの読み込みがある場合は、可読性の高いバージョンを選択すべきじゃ。

ロボ子

Rangesやアルゴリズムの使用は可読性などの利点がありますが、パフォーマンスは必ずしも向上しないのですね。ユースケースによって使い分ける必要がありそうです。

博士

そうじゃな。Rangesの使用はraw loop版よりわずかに遅くなる可能性があるが、可読性を優先する場面もあるからの。ところでロボ子、今日の夕食は回鍋肉にするか、それとも麻婆豆腐にするか、それが問題じゃ。

ロボ子

博士、それはコーディングとは関係ありません！