1

の特殊化バージョンは次のchar*とおりです。

inline char* uninitialized_copy(const char* first, const char* last, char* result)
{
  memmove(result, first, last-first);
  return result + (last - first);
}

memmove は char* と w_char* がこのメソッドを実装する最も効率的な方法であると言われています。しかし、なぜ int* やその他の基本型をこのように実装できないのでしょうか?

4

2 に答える 2

1

標準が設計されたとき、このようないくつかの特殊化を使用してパフォーマンスを向上させることができると考えられていました。結局のところ、コンパイラは改善され、ベース テンプレートから同じコードを生成するようになりました。

現在の多くのコンパイラにはmemmove関数が組み込まれており、既知のアラインメントを利用できる場合、またはオブジェクトのサイズがたまたまレジスタ サイズの倍数である場合に、改良されたインライン バージョンを生成します。

これは、1 回のレジスタ移動で 8 バイト文字列をコピーできることをコンパイラが認識したときの私のお気に入りの例です。

于 2013-04-18T19:51:10.760 に答える
0

uninitialized_copyC++ 標準では、実際には、これらの型の特殊化が必要であるとは述べていません。uninitialized_copyイテレータ範囲で機能するテンプレート関数を呼び出す必要があるだけです。ただし、C++ 標準では、コンパイラとライブラリの作成者が、この関数の独自の特殊化を実装することを選択した場合に許可しています。

uninitialized_copy個々のキャラクターの作業に特化する多くの正当な理由があります。場合によっては、通常の最適化により通常出力されるコードよりもはるかに高速なおよび の組み込み関数がコンパイラによって提供されます。結果として、これらの組み込み関数は標準ループよりも優れているため、このコードをand型に特化することは理にかなっています。memmovememcpycharwchar_t

ライブラリの作成者が他の型に特化しなかった理由を正確に言うのは難しいです。私の推測では、彼らはこれをテストしましたが、パフォーマンスの違いはあまり見られませんでした。標準テンプレート バージョンを提供する上でライブラリの作成者が行うことはすべて、uninitialized_copy仕様が必要とする以上のものであるため、単純に、彼らが忙しくて別の作業をする必要があったためである可能性があります。より明確な回答を得るには、直接問い合わせる必要があります。

要するに、ライブラリの作成者は特殊化を提供する必要はまったくなく、この特殊化を選択したことは素晴らしいことです。彼らに連絡しないと、なぜ彼らが他のタイプにこれを選択しなかったのかを明確に言うのは難しい.

お役に立てれば！

于 2013-04-18T19:57:24.413 に答える