blocks|key|2971206|text|使用-03编译可以为我提供以下内容：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2971207|f：|2971208|++++pushl+++%25ebp
++++movl++++%25esp,+%25ebp
++++cmpl++++$1,+8(%25ebp)
++++popl++++%25ebp
++++sbbl++++%25eax,+%25eax
++++andb++++$58,+%25al
++++addl++++$99,+%25eax
++++ret|code-block|syntax|javascript|2971209|g：|2971210|++++pushl+++%25ebp
++++movl++++%25esp,+%25ebp
++++cmpb++++$1,+8(%25ebp)
++++popl++++%25ebp
++++sbbl++++%25eax,+%25eax
++++andb++++$58,+%25al
++++addl++++$99,+%25eax
++++ret|2971211|。。因此，除了cmpl和cmpb之外，它编译成的代码基本上是相同的。这意味着差异，如果有的话，并不重要。通过未优化的代码来判断是不公平的。|2971212|2971213|编辑来澄清我的观点。未优化的代码是为了简单的调试，而不是为了速度。比较未优化代码的速度是毫无意义的。|BOLD|2971214|entityMap^0|2|3|0|0|0|0|0|7|4|C|4|0|0|0|2|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|14|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|15|8|@$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|1B|8|@$9|1C|A|1D|B|V]]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|X|$]]

Compiling with <code>-03</code> gives the following for me:

f:

<pre><code> pushl %ebp
 movl %esp, %ebp
 cmpl $1, 8(%ebp)
 popl %ebp
 sbbl %eax, %eax
 andb $58, %al
 addl $99, %eax
 ret
</code></pre>

g: 

<pre><code> pushl %ebp
 movl %esp, %ebp
 cmpb $1, 8(%ebp)
 popl %ebp
 sbbl %eax, %eax
 andb $58, %al
 addl $99, %eax
 ret
</code></pre>

.. so it compiles to essentially the same code, except for <code>cmpl</code> vs <code>cmpb</code>.
This means that the difference, if there is any, doesn't matter. Judging by unoptimized code is not fair.

<hr>

Edit to clarify my point. Unoptimized code is for simple debugging, not for speed. Comparing the speed of unoptimized code is senseless.

blocks|key|272632|text|至少在Linux和Windows上安装了GCC+4.5，sizeof(bool)+==+1。在x86和x86_64上，您不能将小于通用目的寄存器的值传递给函数(无论是通过堆栈还是寄存器，取决于调用约定等)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|272633|因此，在未优化时，bool代码实际上会花费一定的时间从参数堆栈中提取布尔值(使用另一个堆栈槽来保存该字节)。这比仅仅提取一个本机寄存器大小的变量要复杂得多。|272634|entityMap^0|S|H|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

With GCC 4.5 on Linux and Windows at least, <code>sizeof(bool) == 1</code>. On x86 and x86_64, you can't pass in less than an general purpose register's worth to a function (whether via the stack or a register depending on the calling convention etc...).

So the code for bool, when un-optimized, actually goes to some length to extract that bool value from the argument stack (using another stack slot to save that byte). It's more complicated than just pulling a native register-sized variable.

blocks|key|269036|text|对我来说很有意义。您的编译器显然将bool定义为一个8位的值，并且您的系统ABI要求它在将小的(<+32位)整数参数推送到调用栈时将它们“提升”为32位。因此，为了比较bool，编译器生成代码来隔离g接收的32位参数的最低有效字节，并将其与cmpb进行比较。在第一个示例中，int参数使用推送到堆栈上的全部32位，因此它只是使用cmpl与整个情况进行比较。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|269037|entityMap^0|H|4|2C|4|3C|4|3T|3|4K|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|G|$]]

Makes sense to me. Your compiler apparently defines a <code>bool</code> as an 8-bit value, and your system ABI requires it to "promote" small (&lt; 32-bit) integer arguments to 32-bit when pushing them onto the call stack. So to compare a <code>bool</code>, the compiler generates code to isolate the least significant byte of the 32-bit argument that g receives, and compares it with <code>cmpb</code>. In the first example, the <code>int</code> argument uses the full 32 bits that were pushed onto the stack, so it simply compares against the whole thing with <code>cmpl</code>.

blocks|key|3185022|text|当我使用一组合理的选项(特别是-O3)编译它时，我得到的结果如下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3185023|对于f()|offset|length|style|CODE|3185024|++++++++.type+++_Z1fi,+@function
_Z1fi:
.LFB0:
++++++++.cfi_startproc
++++++++.cfi_personality+0x3,__gxx_personality_v0
++++++++cmpl++++$1,+%25edi
++++++++sbbl++++%25eax,+%25eax
++++++++andb++++$58,+%25al
++++++++addl++++$99,+%25eax
++++++++ret
++++++++.cfi_endproc|code-block|syntax|javascript|3185025|对于g()|3185026|++++++++.type+++_Z1gb,+@function
_Z1gb:
.LFB1:
++++++++.cfi_startproc
++++++++.cfi_personality+0x3,__gxx_personality_v0
++++++++cmpb++++$1,+%25dil
++++++++sbbl++++%25eax,+%25eax
++++++++andb++++$58,+%25al
++++++++addl++++$99,+%25eax
++++++++ret
++++++++.cfi_endproc|3185027|它们仍然使用不同的指令进行比较(+boolean使用cmpb，而int使用cmpl+)，但除此之外，主体是相同的。快速浏览一下英特尔手册会告诉我：...什么都不是。英特尔手册中没有cmpb或cmpl这样的东西。它们都是cmp的，我现在找不到时刻表。然而，我猜测，比较字节立即数与比较长立即数之间没有时钟差异，因此在所有实际目的中，代码都是相同的。|3185028|3185029|根据您添加的内容进行编辑以添加以下内容|3185030|在未优化的情况下，代码不同的原因是它未优化。(是的，我知道它是圆形的。)当编译器遍历AST并直接生成代码时，它不“知道”任何东西，除了它所在的AST的紧要点。在这一点上，它缺乏所需的所有上下文信息，无法知道在这一点上它可以将声明的类型bool视为int。显然，在默认情况下，布尔值被视为一个字节，在Intel中操作字节时，您必须做一些事情，如符号扩展，使其达到一定的宽度，将其放入堆栈，等等。(您不能推入字节。)|3185031|然而，当优化器查看AST并发挥它的魔力时，它会查看周围的上下文，并“知道”何时可以在不更改语义的情况下用更高效的代码替换代码。因此，它“知道”它可以在参数中使用整数，从而消除不必要的转换和扩大。|3185032|entityMap^0|0|2|3|0|0|2|3|0|0|Q|4|11|4|2I|4|2N|4|31|3|0|0|0|39|4|3F|3|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@$D|13|E|14|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|15|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|16|8|@$D|17|E|18|F|G]]|9|@]|A|$]]|$1|O|3|P|5|J|7|19|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|1A|8|@$D|1B|E|1C|F|G]|$D|1D|E|1E|F|G]|$D|1F|E|1G|F|G]|$D|1H|E|1I|F|G]|$D|1J|E|1K|F|G]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1M|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1N|8|@$D|1O|E|1P|F|G]|$D|1Q|E|1R|F|G]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1S|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|10|$]]

When I compile this with a sane set of options (specifically -O3), here's what I get:

For <code>f()</code>:

<pre><code> .type _Z1fi, @function
_Z1fi:
.LFB0:
 .cfi_startproc
 .cfi_personality 0x3,__gxx_personality_v0
 cmpl $1, %edi
 sbbl %eax, %eax
 andb $58, %al
 addl $99, %eax
 ret
 .cfi_endproc
</code></pre>

For <code>g()</code>:

<pre><code> .type _Z1gb, @function
_Z1gb:
.LFB1:
 .cfi_startproc
 .cfi_personality 0x3,__gxx_personality_v0
 cmpb $1, %dil
 sbbl %eax, %eax
 andb $58, %al
 addl $99, %eax
 ret
 .cfi_endproc
</code></pre>

They still use different instructions for the comparison (<code>cmpb</code> for boolean vs. <code>cmpl</code> for int), but otherwise the bodies are identical. A quick look at the Intel manuals tells me: ... not much of anything. There's no such thing as <code>cmpb</code> or <code>cmpl</code> in the Intel manuals. They're all <code>cmp</code> and I can't find the timing tables at the moment. I'm guessing, however, that there's no clock difference between comparing a byte immediate vs. comparing a long immediate, so for all practical purposes the code is identical.

<hr>

edited to add the following based on your addition

The reason the code is different in the unoptimized case is that it is unoptimized. (Yes, it's circular, I know.) When the compiler walks the AST and generates code directly, it doesn't "know" anything except what's at the immediate point of the AST it's in. At that point it lacks all contextual information needed to know that at this specific point it can treat the declared type <code>bool</code> as an <code>int</code>. A boolean is obviously by default treated as a byte and when manipulating bytes in the Intel world you have to do things like sign-extend to bring it to certain widths to put it on the stack, etc. (You can't push a byte.)

When the optimizer views the AST and does its magic, however, it looks at surrounding context and "knows" when it can replace code with something more efficient without changing semantics. So it "knows" it can use an integer in the parameter and thereby lose the unnecessary conversions and widening.

blocks|key|2971363|text|这在很大程度上取决于编译器和优化。这里有一个有趣的讨论(语言不可知论)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2971364|Does+"if+([bool]+==+true)"+require+one+more+step+than+"if+([bool])"?|offset|length|2971365|另外，看看这篇文章：http://www.linuxquestions.org/questions/programming-9/c-compiler-handling-of-boolean-variables-290996/|2971366|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1070063/does-if-bool-true-require-one-more-step-than-if-bool|1|http://www.linuxquestions.org/questions/programming-9/c-compiler-handling-of-boolean-variables-290996/^0|0|0|1W|0|0|A|2U|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

It will mostly depend on the compiler and the optimization. There's an interesting discussion (language agnostic) here:

<a href="https://stackoverflow.com/questions/1070063/does-if-bool-true-require-one-more-step-than-if-bool">Does &quot;if ([bool] == true)&quot; require one more step than &quot;if ([bool])&quot;?</a>

Also, take a look at this post: <a href="http://www.linuxquestions.org/questions/programming-9/c-compiler-handling-of-boolean-variables-290996/" rel="nofollow noreferrer">http://www.linuxquestions.org/questions/programming-9/c-compiler-handling-of-boolean-variables-290996/</a>

blocks|key|274551|text|在机器级别，没有bool这样的东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|274552|很少有指令集体系结构定义任何类型的布尔操作数类型，尽管经常有指令触发对非零值的操作。对于CPU来说，通常一切都是一个标量类型或一个标量类型字符串。|274553|给定的编译器和给定的ABI将需要为int和bool选择特定的大小，当这些大小不同时，就像您的情况一样，它们可能会生成略有不同的代码，并且在某些优化级别上可能会更快一些。|offset|length|style|CODE|274554|为什么在许多系统上bool是一个字节？|274555|为bool选择一个char类型会更安全，因为某些人可能会创建一个非常大的数组。|274556|更新:我所说的“更安全”是指:对于编译器和库实现者。我并不是说人们需要重新实现系统类型。|274557|entityMap^0|0|0|H|3|L|4|0|0|9|4|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@$F|U|G|V|H|I]|$F|W|G|X|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|Z|8|@$F|10|G|11|H|I]]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|Q|$]]

<h3>At the machine level there is no such thing as bool</h3>

Very few instruction set architectures define any sort of boolean operand type, although there are often instructions that trigger an action on non-zero values. To the CPU, usually, everything is one of the scalar types or a string of them. 

A given compiler and a given ABI will need to choose specific sizes for <code>int</code> and <code>bool</code> and when, like in your case, these are different sizes they may generate slightly different code, and at some levels of optimization one may be slightly faster.

<h3>Why is bool one byte on many systems?</h3>

It's safer to choose a <code>char</code> type for bool because someone might make a really large array of them.

Update: by "safer", I mean: for the compiler and library implementors. I'm not saying people need to reimplement the system type.

blocks|key|2971398|text|是啊，讨论很有趣。但只需要测试一下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2971399|测试代码：|2971400|#include+<stdio.h>
#include+<string.h>

int+testi(int);
int+testb(bool);
int+main+(int+argc,+char*+argv[]){
++bool+valb;
++int++vali;
++int+loops;
++if(+argc+<+2+){
++++return+2;
++}
++valb+=+(0+!=+(strcmp(argv[1],+"0")));
++vali+=+strcmp(argv[1],+"0");
++printf("Arg1:+%25s\n",+argv[1]);
++printf("BArg1:+%25i\n",+valb+?+1+:+0);
++printf("IArg1:+%25i\n",+vali);
++for(loops=30000000;+loops>0;+loops--){
++++//printf("%25i:+%25i\n",+loops,+testb(valb=!valb));
++++printf("%25i:+%25i\n",+loops,+testi(vali=!vali));
++}
++return+valb;
}

int+testi(int+val){
++if(+val+){
++++return+1;
++}
++return+0;
}
int+testb(bool+val){
++if(+val+){
++++return+1;
++}
++return+0;
}|code-block|syntax|javascript|2971401|在64位Ubuntu10.10笔记本电脑上编译:+g%2B%2B+-O3+-o+/tmp/test_i+/tmp/test_i.cpp|2971402|基于整数的比较：|2971403|sauer@trogdor:/tmp$+time+/tmp/test_i+1+>+/dev/null

real++++0m8.203s
user++++0m8.170s
sys+0m0.010s
sauer@trogdor:/tmp$+time+/tmp/test_i+1+>+/dev/null

real++++0m8.056s
user++++0m8.020s
sys+0m0.000s
sauer@trogdor:/tmp$+time+/tmp/test_i+1+>+/dev/null

real++++0m8.116s
user++++0m8.100s
sys+0m0.000s|2971404|布尔测试/打印未注释(和整数注释)：|2971405|sauer@trogdor:/tmp$+time+/tmp/test_i+1+>+/dev/null

real++++0m8.254s
user++++0m8.240s
sys+0m0.000s
sauer@trogdor:/tmp$+time+/tmp/test_i+1+>+/dev/null

real++++0m8.028s
user++++0m8.000s
sys+0m0.010s
sauer@trogdor:/tmp$+time+/tmp/test_i+1+>+/dev/null

real++++0m7.981s
user++++0m7.900s
sys+0m0.050s|2971406|它们是相同的，1个赋值和2个比较，每个循环超过3000万次循环。找一些其他的东西来优化。例如，不要不必要地使用strcmp。;)|2971407|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|11|8|@]|9|@]|A|$G|H]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|13|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

Yeah, the discussion's fun. But just test it:

Test code:

<pre><code>#include &lt;stdio.h&gt;
#include &lt;string.h&gt;

int testi(int);
int testb(bool);
int main (int argc, char* argv[]){
 bool valb;
 int vali;
 int loops;
 if( argc &lt; 2 ){
 return 2;
 }
 valb = (0 != (strcmp(argv[1], "0")));
 vali = strcmp(argv[1], "0");
 printf("Arg1: %s\n", argv[1]);
 printf("BArg1: %i\n", valb ? 1 : 0);
 printf("IArg1: %i\n", vali);
 for(loops=30000000; loops&gt;0; loops--){
 //printf("%i: %i\n", loops, testb(valb=!valb));
 printf("%i: %i\n", loops, testi(vali=!vali));
 }
 return valb;
}

int testi(int val){
 if( val ){
 return 1;
 }
 return 0;
}
int testb(bool val){
 if( val ){
 return 1;
 }
 return 0;
}
</code></pre>

Compiled on a 64-bit Ubuntu 10.10 laptop with:
 g++ -O3 -o /tmp/test_i /tmp/test_i.cpp

Integer-based comparison:

<pre><code>sauer@trogdor:/tmp$ time /tmp/test_i 1 &gt; /dev/null

real 0m8.203s
user 0m8.170s
sys 0m0.010s
sauer@trogdor:/tmp$ time /tmp/test_i 1 &gt; /dev/null

real 0m8.056s
user 0m8.020s
sys 0m0.000s
sauer@trogdor:/tmp$ time /tmp/test_i 1 &gt; /dev/null

real 0m8.116s
user 0m8.100s
sys 0m0.000s
</code></pre>

Boolean test / print uncommented (and integer commented):

<pre><code>sauer@trogdor:/tmp$ time /tmp/test_i 1 &gt; /dev/null

real 0m8.254s
user 0m8.240s
sys 0m0.000s
sauer@trogdor:/tmp$ time /tmp/test_i 1 &gt; /dev/null

real 0m8.028s
user 0m8.000s
sys 0m0.010s
sauer@trogdor:/tmp$ time /tmp/test_i 1 &gt; /dev/null

real 0m7.981s
user 0m7.900s
sys 0m0.050s
</code></pre>

They're the same with 1 assignment and 2 comparisons each loop over 30 million loops. Find something else to optimize. For example, don't use strcmp unnecessarily. ;)

blocks|key|3185199|text|用两种不同的方式回答你的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3185200|如果你特别谈论的是C%2B%2B或任何可以产生汇编代码的编程语言，我们就会考虑到编译器会在ASM中产生什么样的代码。我们还被绑定到c%2B%2B中true和false的表示。一个整数必须存储在32位中，我可以简单地使用一个字节来存储布尔表达式。条件语句的Asm代码段：|3185201|对于整数：|3185202|++mov+eax,dword+ptr[esp]++++;Store+integer
++cmp+eax,0+++++++++++++++++;Compare+to+0
++je++false+++++++++++++++++;If+int+is+0,+its+false
++;Do+what+has+to+be+done+when+true
false:
++;Do+what+has+to+be+done+when+false|code-block|syntax|javascript|3185203|对于bool：|3185204|++mov++al,1+++++;Anything+that+is+not+0+is+true
++test+al,1+++++;See+if+first+bit+is+fliped
++jz+++false++++;Not+fliped,+so+it's+false
++;Do+what+has+to+be+done+when+true
false:
++;Do+what+has+to+be+done+when+false|3185205|因此，这就是为什么速度比较如此依赖于编译。在上面的例子中，布尔会稍微快一点，因为cmp会暗示一个用于设置标志的减法。它也与您的编译器生成的内容相矛盾。|offset|length|style|CODE|3185206|另一种更简单的方法是单独查看表达式的逻辑，尽量不要担心编译器将如何翻译代码，我认为这是一种更健康的思考方式。我仍然相信，归根结底，编译器生成的代码实际上是试图给出一个真实的解决方案。我的意思是，如果您在if语句中增加测试用例，并坚持在一边使用boolean，在另一边使用整数，编译器就会这样做，这样生成的代码将在机器级别上使用布尔表达式执行得更快。|3185207|我认为这是一个概念性的问题，所以我会给出一个概念性的答案。这个讨论让我想起了我经常讨论的关于代码效率是否会转化为汇编中更少的代码行的讨论。似乎这个概念被普遍认为是正确的。考虑到跟踪ALU处理每条语句的速度是不可行的，第二种选择是专注于汇编中的跳转和比较。在这种情况下，您所展示的代码中布尔语句和整数之间的区别就变得相当具有代表性。C%2B%2B中表达式的结果将返回一个值，然后该值将被赋予表示形式。另一方面，在汇编中，跳转和比较将基于数值，而不管在C%2B%2B+if语句中返回的是哪种类型的表达式。在这些问题上，重要的是要记住，像这样的纯逻辑语句最终会有巨大的计算开销，即使只有一位也能做同样的事情。|3185208|entityMap^0|0|0|0|0|0|0|14|3|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|15|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|16|8|@$Q|17|R|18|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|19|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Z|$]]

Approaching your question in two different ways:

If you are specifically talking about C++ or any programming language that will produce assembly code for that matter, we are bound to what code the compiler will generate in ASM. We are also bound to the representation of true and false in c++. An integer will have to be stored in 32 bits, and I could simply use a byte to store the boolean expression. Asm snippets for conditional statements:

For the integer:

<pre><code> mov eax,dword ptr[esp] ;Store integer
 cmp eax,0 ;Compare to 0
 je false ;If int is 0, its false
 ;Do what has to be done when true
false:
 ;Do what has to be done when false
</code></pre>

For the bool:

<pre><code> mov al,1 ;Anything that is not 0 is true
 test al,1 ;See if first bit is fliped
 jz false ;Not fliped, so it's false
 ;Do what has to be done when true
false:
 ;Do what has to be done when false
</code></pre>

So, that's why the speed comparison is so compile dependent. In the case above, the bool would be slightly fast since <code>cmp</code> would imply a subtraction for setting the flags. It also contradicts with what your compiler generated.

Another approach, a much simpler one, is to look at the logic of the expression on it's own and try not to worry about how the compiler will translate your code, and I think this is a much healthier way of thinking. I still believe, ultimately, that the code being generated by the compiler is actually trying to give a truthful resolution. What I mean is that, maybe if you increase the test cases in the if statement and stick with boolean in one side and integer in another, the compiler will make it so the code generated will execute faster with boolean expressions in the machine level.

I'm considering this is a conceptual question, so I'll give a conceptual answer. This discussion reminds me of discussions I commonly have about whether or not code efficiency translates to less lines of code in assembly. It seems that this concept is generally accepted as being true. Considering that keeping track of how fast the ALU will handle each statement is not viable, the second option would be to focus on jumps and compares in assembly. When that is the case, the distinction between boolean statements or integers in the code you presented becomes rather representative. The result of an expression in C++ will return a value that will then be given a representation. In assembly, on the other hand, the jumps and comparisons will be based in numeric values regardless of what type of expression was being evaluated back at you C++ if statement. It is important on these questions to remember that purely logicical statements such as these end up with a huge computational overhead, even though a single bit would be capable of the same thing.

<blockquote>
 <a href="https://stackoverflow.com/questions/5554725/which-value-is-better-to-use-boolean-true-or-integer-1">Which value is better to use? Boolean true or Integer 1?</a>
</blockquote>

The above topic made me do some experiments with <code>bool</code> and <code>int</code> in <code>if</code> condition. So just out of curiosity I wrote this program:

<pre><code>int f(int i) 
{
 if ( i ) return 99; //if(int)
 else return -99;
}
int g(bool b)
{
 if ( b ) return 99; //if(bool)
 else return -99;
}
int main(){}
</code></pre>

<code>g++ intbool.cpp -S</code> generates asm code for each functions as follows:

<ul>
<li>asm code for <code>f(int)</code>

<pre><code>__Z1fi:
 LFB0:
 pushl %ebp
 LCFI0:
 movl %esp, %ebp
 LCFI1:
 cmpl $0, 8(%ebp)
 je L2
 movl $99, %eax
 jmp L3
 L2:
 movl $-99, %eax
 L3:
 leave
 LCFI2:
 ret
</code></pre></li>
<li>asm code for <code>g(bool)</code>

<pre><code>__Z1gb:
 LFB1:
 pushl %ebp
 LCFI3:
 movl %esp, %ebp
 LCFI4:
 subl $4, %esp
 LCFI5:
 movl 8(%ebp), %eax
 movb %al, -4(%ebp)
 cmpb $0, -4(%ebp)
 je L5
 movl $99, %eax
 jmp L6
 L5:
 movl $-99, %eax
 L6:
 leave
 LCFI6:
 ret
</code></pre></li>
</ul>

Surprisingly, <code>g(bool)</code> generates more <code>asm</code> instructions! Does it mean that <code>if(bool)</code> is little slower than <code>if(int)</code>? I used to think <code>bool</code> is especially designed to be used in conditional statement such as <code>if</code>, so I was expecting <code>g(bool)</code> to generate less asm instructions, thereby making <code>g(bool)</code> more efficient and fast. 

EDIT:

I'm not using any optimization flag as of now. But even absence of it, why does it generate more asm for <code>g(bool)</code> is a question for which I'm looking for a reasonable answer. I should also tell you that <code>-O2</code> optimization flag generates exactly same asm. But that isn't the question. The question is what I've asked.

<hr>

Which is faster : if (bool) or if(int)?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

 上面的主题让我在if环境下用bool和int做了一些实验。出于好奇，我写了这个程序：int f(int i) {    if ( i ) return 99;   //if(int)    else  return -99;}int g(bool b){    if ( b ) return 99;   //if(b...

问哪个更快: if (bool)和if(int)？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问哪个更快: if (bool)和if(int)？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问哪个更快: if (bool)和if(int)？
EN