c - ブール定義

Question

BOOL データ型が容易に事前定義されない場合は常に、次の定義でブール値を使用していました。

typedef unsigned char BOOL;

（メモリ使用量のため）。

パフォーマンス上の理由から、ネイティブのバス幅を使用する方がよい場合があることに気付きました。たとえば、32 ビットプロセッサの場合は次のようになります。

typedef unsigned int BOOL;

さて、ネイティブバス幅に BOOL を定義したい場合、64 ビットプロセッサはどうなるでしょうか。

score 13 · Accepted Answer

ネイティブのバス幅については、効率的な幅ほど気にしません(それがあなたの目標でしたね)。ほぼすべてのマシンで、まともな c コンパイラはunsigned intかなり効率的な幅にコンパイルされるので、問題ありません。

score 9 · Accepted Answer

パフォーマンスを推測しないでください。測定すると、何が優れているかについて決定的な答えが得られます。これは、新しいコンパイラのバージョン、システムのアップグレードごとに変わる可能性があることを覚えておいてください...

また、ある日、ブール値の配列が必要になる場合があります。その場合、ブール値にプロセッサワードを使用することは最善の解決策ではありません。

score 5 · Accepted Answer

5

stdbool.hで bool 型を使用しないのはなぜですか?

于 2009-03-06T05:42:15.343 に答える

score 4 · Accepted Answer

4

size_t

于 2009-03-06T05:37:06.590 に答える

score 3 · Accepted Answer

プリプロセッサを使用することをお勧めします。

 #ifndef BOOL 
   #ifdef ILP32
     #define BOOL uint32_t
   #endif
   #ifdef LP64
     #define BOOL uint64_t
   #endif
 #endif

score 2 · Accepted Answer

少なくとも x86 と ARM は、ペナルティなしで 32 ビットレジスタとの間でバイトをロードおよびストアすることができるため、char を使用してもパフォーマンスに影響はありません。完全にはわかりませんが、x86-64にもそのような命令があるに違いありません。(もちろん、x86 と x86-64 では、8 ビット値をレジスタで直接処理することもできます)。

したがって、唯一の懸念はメモリレイアウトに関するものかもしれません。もちろん、コンパイラはすべてを整列するため、ほとんどの場合、構造体の char 値は互いに隣接していない限りパディングされます。実際には、数バイトのスペースを節約し、キャッシュパフォーマンスをわずかに向上させることができます。BOOL の巨大な配列があり、メモリが問題になる場合は、とにかくそれらをビットパックする必要があります。

いずれにせよ、それは問題ではありません。両方の方法でコンパイルされたプログラムを実行してみて、パフォーマンスやメモリ使用量に重大な影響があるかどうかを確認してみてください。あることがわかったら、自分でビールを買って、私からのふりをすることができます.

score 0 · Accepted Answer

いつでも typedef をlong long何かに定義することができますが、実際には、これが何らかの理由で人々が行うことであるかどうかはわかりません。(おそらく sizeof(int*) などに基づいて条件付き定義を行うこともできます)。

score 0 · Accepted Answer

0

char を使用すると、integer を使用するよりも遅くなる可能性があります。

于 2009-03-06T06:10:34.357 に答える

c - ブール定義

10 に答える 10

Related

Reference