4

問題 copy vs. memcpy vs memmoveに関して(ここで優れ た情報、ところで)、私は読んでいて、口頭で言われていることとは異なり、たとえばcppreference注: memcpy はに変更されましたこの引用を受け取ってからmemmove。 --

ノート

実際には、 の実装ではstd::copy複数の代入を避けstd::memcpy、値の型が TriviallyCopyable

-- std::copy(nor std::copy_backward)は、宛先範囲の先頭のみがソース範囲に入ってはならず、範囲全体が重複してはならないため、 に関して実装することはできません。memcopystd::copymemcpy

Visual-C++ の実装 (xutilityヘッダーを参照) を見ると、VC++ がmemmoveを使用していることもわかりますが、現在は よりも要件が緩和されていますstd::copy。

... オブジェクトがオーバーラップする可能性があります。コピーは、文字が一時的な文字配列にコピーされ、次に文字が配列からコピーされたかのように行われます ...

したがってstd::copy、の観点からの実装memcpyは不可能に見えますが、使用memmoveは実際にはペシミゼーションです。（ほんの少しの悲観化、おそらく測定できないかもしれませんが、それでも）

質問に戻るには:私の要約は正しいですか? これはどこかで問題がありますか？指定されているものに関係なく、memcpyの要件も満たさないの実用std::copy的なmemcpy実装の可能性さえありstd::copyますか?

4

1 に答える 1

2

問題が、重複する範囲でそれを信頼しないのに十分な未定義の動作を備えた効率的な memcpy 実装に遭遇する可能性があるかどうかである場合、答えはイエスです。:-)

Power(PC) アーキテクチャでの memcpy の可能な実装の 1 つを考えてみましょう。lmw 命令は、複数の連続するワードをメモリから連続するレジスタ (ユーザー定義の範囲引数として指定できます) にロードします。stmw は、指定されたレジスタ範囲をメモリに保存します。したがって、1 回の memcpy 反復中に CPU によってバッファリングされる約 100/200 バイト (32b/64b CPU) について話している - 特に CPU が約束をしないことを考えると、ターゲット範囲がソース範囲とオーバーラップする場合、ターゲット範囲を台無しにする大量のデータ個々のロードとストアの相対的な順序について。

于 2013-10-29T03:12:56.963 に答える