48

私の理解では、C ++ reinterpret_castとCポインターキャストは単なるコンパイル時の機能であり、パフォーマンスコストはまったくありません。

これは本当ですか？

4

7 に答える 7

62

最初から始めるのは良い仮定です。ただし、オプティマイザーは、reinterpret_cast<>またはCポインターのキャストが存在する場合に想定できるものに制限される場合があります。次に、キャスト自体に関連する命令がない場合でも、結果のコードは遅くなります。

たとえば、intをポインターにキャストした場合、オプティマイザーはそのポインターが何を指しているのかわからない可能性があります。結果として、おそらく、そのポインターを介した書き込みによって任意の変数が変更される可能性があると想定する必要があります。これは、変数をレジスタに格納するなどの非常に一般的な最適化に勝るものです。

于 2010-08-26T13:09:56.777 に答える
6

それは正しい。新しい幅で命令を実行するためのパフォーマンスの向上/低下以外のコストはありませんが、これはまれなケースでのみ問題になります。私が今まで聞いたすべてのプラットフォームでポインター間をキャストしても、コストはゼロであり、パフォーマンスの変化はまったくありません。

于 2010-08-26T12:59:55.713 に答える
5

C ++でのCスタイルのキャストは、最初にstatic_castを試行し、静的キャストを実行できない場合にのみreinterpret_castを実行します。static_castは、多重継承の場合（または、インターフェイスを具象型にキャストする場合）にポインターの値を変更する場合があり、このオフセット計算には追加のマシン命令が含まれる場合があります。これはせいぜい1つのマシン命令になるので、本当に非常に小さいです。

于 2010-08-26T14:17:27.650 に答える
2

ええそれはそうです。実行時コストのあるキャストタイプはdynamic_castです。

于 2010-08-26T12:59:52.307 に答える
2

その通りですが、考えてみてください。reinterpret_castは、デザインが悪いか、非常に低いレベルで何かをしていることを意味します。

代わりに動的キャストは、実行時にルックアップテーブルを調べる必要があるため、コストがかかります。

于 2010-08-26T13:04:01.477 に答える
1

reinterpret_cast実行時のコストは発生しません。ただし、使用するたびにreinterpret_cast実装が定義されるため、注意が必要です。たとえば、char配列を配列として再解釈するintと、ターゲットアーキテクチャが割り込みをスローする可能性があります。これは、タイプが異なればアライメントルールも異なる可能性があるためです。

最初に正解してから、効率について心配してください。

于 2010-08-26T13:06:40.397 に答える
0

符号付き文字を符号なし文字としてキャストすることを再解釈する前後に、アセンブラコードを見ていました。指示はさらに約3つまたは4つの指示によって増加しました。

int main()
{
 signed char i = 0x80;
 (unsigned char&)i >>= 7;
 return i;
}

unsigned charにキャストして、コンパイラがSAR命令ではなくSHL命令を使用するようにしました。これにより、ビットの新しくシフトされたシフトは、vari符号付きビット値ではなくzer0sになります。

コンパイラはまだ、常にSAR命令を使用しているようです。しかし、キャストを再解釈すると、コンパイラーはさらに命令を追加しました。さらに3〜4つの指示！

UTF8をUTF16文字列に変換するためのUnicode関数がWin32MultiByteToWideChar（）よりもほぼ3倍遅い理由が心配でした。今、私はキャスティングが主な要因の1つであることが心配です。

スピードのためにキャストを再解釈するので、これはIRONICです。

于 2021-01-17T00:35:52.143 に答える