blocks|key|412087|text|为什么不是这个呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|412088|if+(newpos+!=+oldpos)+{
++++...
}|code-block|syntax|javascript|412089|由于缺少abs()，因此比两者都更高效，而且引导更清晰。|offset|length|style|CODE|412090|entityMap^0|0|0|4|5|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Why not this?

<pre><code>if (newpos != oldpos) {
 ...
}
</code></pre>

More efficient than both due to the lack of <code>abs()</code>, and clearer to boot.

blocks|key|2727576|text|不改变的一个主要原因|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2727577|(abs(newpos-oldpos)+>+1)|code-block|syntax|javascript|2727578|至|2727579|(abs(newpos-oldpos)+!=+0)|2727580|它们在语义上是不同的。|2727581|当使用abs(newpos-oldpos)+==+1时，你会得到不同的结果。这是一个例子，说明了为什么你应该“仅仅因为”而不愿意改变事情--除了这样一个事实，即无论如何都不会有可测量的性能差异(也可能也没有实际的差异)。|offset|length|style|CODE|2727582|entityMap^0|0|0|0|0|0|3|N|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@$O|10|P|11|Q|R]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

A major reason not to change 

<pre><code>(abs(newpos-oldpos) &gt; 1)
</code></pre>

to 

<pre><code>(abs(newpos-oldpos) != 0)
</code></pre>

is that they are semantically different.

When <code>abs(newpos-oldpos) == 1</code> you get different results. This is an example of why you should be reluctant to change things 'just because' - aside from the fact that there would be no measurable difference in performance anyway (and probably no actual difference either).

blocks|key|4193427|text|如果去掉不必要的abs()，第二个方法会更有效。如果要与零进行比较，差异是正还是负都无关紧要。此外，我认为它更具可读性。然而，这两个条件似乎并不等价；如果abs(newpos-oldpos)+==+1会发生什么？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4193428|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The second is more efficient if you remove the unnecessary abs(). If you're comparing against zero, it doesn't matter whether the difference is positive or negative. Also, I think it's more readable. However, the two conditionals don't seem equivalent; what happens if abs(newpos-oldpos) == 1?

blocks|key|412199|text|在大多数架构上，应该没有区别。比较通常在CPU中通过执行减法并让ALU设置条件代码来完成。分支是通过测试条件码来完成的(即，不等于时分支测试条件码寄存器中的零位，大于时分支通常测试零、负和溢出标志)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|412200|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

On most architectures, there should be no difference. Comparisons are typically done inside a CPU by doing a subtraction and letting the condition codes get set by the ALU. Branching is done by testing condition codes (ie, branch on not equal tests the zero bit in the condition code register, branch on greater typically tests the zero, negative, and overflow flags).

blocks|key|2727652|text|除非我遗漏了什么，否则他们不会做同样的事情。X>1不等于x+!=+0。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2727653|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Unless I am missing something, they do not do the same thing. x > 1 is not the same as x != 0.

blocks|key|2727412|text|不要试图将比较运算符优化为等于运算符；它们应该具有相同的时间，并且只有整数具有相同的值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2727413|如果要进行优化，请尝试|2727414|if+((newpos+-+oldpos+>+1)+%7C%7C+(oldpos+-+newpos+>+1))|code-block|syntax|javascript|2727415|它仍然是可读的。(对于浮动点#也是一致正确的)|2727416|编辑：+ack！不要紧，如果你想知道位置是否改变了一些最小的增量(我最初从字面上看你的代码问题，但没有看到你试图实现的总体目标)，使用以下命令：|offset|length|style|BOLD|2727417|if+((newpos+-+oldpos+>+delta)+%7C%7C+(oldpos+-+newpos+>+delta))|2727418|对于大于0的增量，或者这个(如Noah+M所建议的)|2727419|if+(newpos+!=+oldpos)|2727420|对于增量=0|2727421|entityMap^0|0|0|0|0|0|3|0|0|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|F|7|12|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|13|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|14|8|@$M|15|N|16|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|F|7|17|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|18|8|@]|9|@]|A|$]]|$1|U|3|V|5|F|7|19|8|@]|9|@]|A|$G|H]]|$1|W|3|X|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Z|$]]

Don't try to optimize comparison operators to equal operators; they should have the same timing, and only have the same value for integers.

If you're going to optimize at all, try

<pre><code>if ((newpos - oldpos &gt; 1) || (oldpos - newpos &gt; 1))
</code></pre>

which is still readable. (as well as consistenly correct for floating pt #s)

edit:
ack! Never mind, if you want to know whether position has changed by some minimum delta (I originally read your code question literally w/o seeing the overall goal you're trying to achieve), use this:

<pre><code>if ((newpos - oldpos &gt; delta) || (oldpos - newpos &gt; delta))
</code></pre>

for delta > 0, or this (as Noah M suggested)

<pre><code>if (newpos != oldpos)
</code></pre>

for delta = 0

blocks|key|412322|text|忽略它们不是等价操作的事实，在x86上，您也许能够节省一个周期。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|412323|abs(new-pos)+>1|412324|将会是|412325|412326|Subtraction|ordered-list-item|412327|Abs|412328|Compare到1|412329|Jmp|412330|412331|abs(newpos-oldpos)+!=+0|412332|412333|412334|412335|412336|Jmp+-如果abs是内联的，并且最后一个操作适当地设置了零标志。|412337|412338|如果这对你的程序有任何可衡量的影响，我会感到惊讶-如果你的代码已经运行得如此之紧，你绝对值得表扬。|412339|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|17|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|18|8|@]|9|@]|A|$]]|$1|L|3|M|5|I|7|19|8|@]|9|@]|A|$]]|$1|N|3|O|5|I|7|1A|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1C|8|@]|9|@]|A|$]]|$1|S|3|E|5|6|7|1D|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|U|3|H|5|I|7|1F|8|@]|9|@]|A|$]]|$1|V|3|K|5|I|7|1G|8|@]|9|@]|A|$]]|$1|W|3|X|5|I|7|1H|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1J|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|12|$]]

Ignoring the fact they are not equivilent operations, on x86, you might be able to save a cycle or so.

abs(new-pos) > 1

Would be

<ol>
<li>Subtraction</li>
<li>Abs</li>
<li>Compare to 1</li>
<li>Jmp</li>
</ol>

abs(newpos-oldpos) != 0

Would be

<ol>
<li>Subtraction</li>
<li>Abs</li>
<li>Jmp - If abs is inlined and the last operation appropriately sets the zero flag.</li>
</ol>

I'd be surprised if this has any measurable impact on your program - You definitely deserve praise if your code is already running that incredibly tight.

blocks|key|412461|text|由于答案将取决于您的架构，让我们来看看x86-64上生成的代码(使用gcc+-O3)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|412462|#include+<math.h>

int+t_gt(int+x)+{+//+note!+not+equivalent+to+the+others
++++return+abs(x)+>+1;
}

int+t_ge(int+x)+{
++++return+abs(x)+>=+1;
}

int+t_ne(int+x)+{
++++return+abs(x)+!=+1;
}|code-block|syntax|javascript|412463|变成：|412464|Disassembly+of+section+.text:

0000000000000000+<t_gt>:
#include+<math.h>

int+t_gt(int+x)+{
+++0:+++89+f8+++++++++++++++++++mov++++%25edi,%25eax
+++2:+++c1+f8+1f++++++++++++++++sar++++$0x1f,%25eax
+++5:+++31+c7+++++++++++++++++++xor++++%25eax,%25edi
+++7:+++29+c7+++++++++++++++++++sub++++%25eax,%25edi
+++9:+++31+c0+++++++++++++++++++xor++++%25eax,%25eax
+++b:+++83+ff+01++++++++++++++++cmp++++$0x1,%25edi
+++e:+++0f+9f+c0++++++++++++++++setg+++%25al
++++return+abs(x)+>+1;
}
++11:+++c3++++++++++++++++++++++retq+++
++12:+++66+66+66+66+66+2e+0f++++nopw+++%25cs:0x0(%25rax,%25rax,1)
++19:+++1f+84+00+00+00+00+00+

0000000000000020+<t_ge>:

int+t_ge(int+x)+{
++20:+++89+f8+++++++++++++++++++mov++++%25edi,%25eax
++22:+++c1+f8+1f++++++++++++++++sar++++$0x1f,%25eax
++25:+++31+c7+++++++++++++++++++xor++++%25eax,%25edi
++27:+++29+c7+++++++++++++++++++sub++++%25eax,%25edi
++29:+++31+c0+++++++++++++++++++xor++++%25eax,%25eax
++2b:+++85+ff+++++++++++++++++++test+++%25edi,%25edi
++2d:+++0f+9f+c0++++++++++++++++setg+++%25al
++++return+abs(x)+>=+1;
}
++30:+++c3++++++++++++++++++++++retq+++
++31:+++66+66+66+66+66+66+2e++++nopw+++%25cs:0x0(%25rax,%25rax,1)
++38:+++0f+1f+84+00+00+00+00+
++3f:+++00+

0000000000000040+<t_ne>:

int+t_ne(int+x)+{
++40:+++89+f8+++++++++++++++++++mov++++%25edi,%25eax
++42:+++c1+f8+1f++++++++++++++++sar++++$0x1f,%25eax
++45:+++31+c7+++++++++++++++++++xor++++%25eax,%25edi
++47:+++29+c7+++++++++++++++++++sub++++%25eax,%25edi
++49:+++31+c0+++++++++++++++++++xor++++%25eax,%25eax
++4b:+++83+ff+01++++++++++++++++cmp++++$0x1,%25edi
++4e:+++0f+95+c0++++++++++++++++setne++%25al
++++return+abs(x)+!=+1;
}
++51:+++c3++++++++++++++++++++++retq+++|412465|如您所见，有两个不同之处：|412466|412467|集合*运算上的条件代码不同。这可能不会影响速度。对于t_ge，使用两个字节的寄存器测试(+and+)，而其他两个使用cmp+(减法)和文字单字节操作数进行比较。|unordered-list-item|412468|412469|虽然各种set*变体之间以及test和cmp之间的差异可能为零，但cmp的额外一个字节操作数可能会以极小的量降低性能。|412470|当然，最好的性能将通过完全摆脱毫无意义的abs()来实现：|412471|0000000000000060+<t_ne2>:

int+t_ne2(int+x)+{
++60:+++31+c0+++++++++++++++++++xor++++%25eax,%25eax
++62:+++85+ff+++++++++++++++++++test+++%25edi,%25edi
++64:+++0f+95+c0++++++++++++++++setne++%25al
++++return+(x+!=+0);
}
++67:+++c3++++++++++++++++++++++retq+++|412472|请记住，这些发现可能不适用于其他架构；然而，在任何地方失去abs肯定会更快。|412473|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|12|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|13|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|14|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|15|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|17|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|19|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1A|8|@]|9|@]|A|$]]|$1|V|3|W|5|D|7|1B|8|@]|9|@]|A|$E|F]]|$1|X|3|Y|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|10|$]]

Since the answer will depend on your architecture, let's take a look at the generated code on x86-64 (with gcc -O3):

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

int t_gt(int x) { // note! not equivalent to the others
 return abs(x) &gt; 1;
}

int t_ge(int x) {
 return abs(x) &gt;= 1;
}

int t_ne(int x) {
 return abs(x) != 1;
}
</code></pre>

becomes:

<pre><code>Disassembly of section .text:

0000000000000000 &lt;t_gt&gt;:
#include &lt;math.h&gt;

int t_gt(int x) {
 0: 89 f8 mov %edi,%eax
 2: c1 f8 1f sar $0x1f,%eax
 5: 31 c7 xor %eax,%edi
 7: 29 c7 sub %eax,%edi
 9: 31 c0 xor %eax,%eax
 b: 83 ff 01 cmp $0x1,%edi
 e: 0f 9f c0 setg %al
 return abs(x) &gt; 1;
}
 11: c3 retq 
 12: 66 66 66 66 66 2e 0f nopw %cs:0x0(%rax,%rax,1)
 19: 1f 84 00 00 00 00 00 

0000000000000020 &lt;t_ge&gt;:

int t_ge(int x) {
 20: 89 f8 mov %edi,%eax
 22: c1 f8 1f sar $0x1f,%eax
 25: 31 c7 xor %eax,%edi
 27: 29 c7 sub %eax,%edi
 29: 31 c0 xor %eax,%eax
 2b: 85 ff test %edi,%edi
 2d: 0f 9f c0 setg %al
 return abs(x) &gt;= 1;
}
 30: c3 retq 
 31: 66 66 66 66 66 66 2e nopw %cs:0x0(%rax,%rax,1)
 38: 0f 1f 84 00 00 00 00 
 3f: 00 

0000000000000040 &lt;t_ne&gt;:

int t_ne(int x) {
 40: 89 f8 mov %edi,%eax
 42: c1 f8 1f sar $0x1f,%eax
 45: 31 c7 xor %eax,%edi
 47: 29 c7 sub %eax,%edi
 49: 31 c0 xor %eax,%eax
 4b: 83 ff 01 cmp $0x1,%edi
 4e: 0f 95 c0 setne %al
 return abs(x) != 1;
}
 51: c3 retq 
</code></pre>

As you can see, there are two differences:

<ul>
<li>The condition codes on the set* ops are different. This likely won't affect speed.</li>
<li>For t_ge, a two-byte register test (AND) is used, while the other two use cmp (subtraction) and a literal one-byte operand to compare against.</li>
</ul>

While the difference between the various set* variants, and between test and cmp is likely zero, the additional one-byte operand to cmp may decrease performance by an immeasurably small amount.

Of course, the best performance will be given by getting rid of the pointless abs() entirely:

<pre><code>0000000000000060 &lt;t_ne2&gt;:

int t_ne2(int x) {
 60: 31 c0 xor %eax,%eax
 62: 85 ff test %edi,%edi
 64: 0f 95 c0 setne %al
 return (x != 0);
}
 67: c3 retq 
</code></pre>

Keep in mind that these findings may not apply on other architectures; however losing the abs is sure to be faster anywhere.

blocks|key|412164|text|性能差异将是微不足道的，但第一个会更有效(从我的猜测)+b/c它涉及的操作比!=更少。此外，这两个语句的含义也不同，例如，尝试abs(newpos+-+oldpos)+=+0.5并查看，除非这两个变量是整数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|412165|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The performance difference would be miniscule, but the first one would be more efficient (from my guess) b/c it involves less operations than !=. Also, the 2 statements mean different things, for example, try abs(newpos - oldpos) = 0.5 and see, unless the two variables are integers.

blocks|key|412368|text|与其猜测编译器会做什么，为什么不看一下结果汇编代码，或者衡量它的执行情况呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|412369|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Instead of guessing what the compiler will do, why not just look at the resulting assembly code, or measure its execution?

blocks|key|4193580|text|我现在不知道是不是我漏掉了什么，但是每本关于浮点数的书上都有这个代码，它的目的是在两个略有不同的数字之间得到一个正匹配。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4193581|如果代码必须比较两个浮点数，在大多数机器上没有可能的优化，但重要的是，这不是关于过早的优化，它是关于重构你不完全理解的代码。|4193582|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I don't now if it's me who is missing something, but that code is on every book about floating point numbers and it is intended to get a positive match between two slightly different numbers.

If the code has to compare two floats there is no possible optimization on most machines but the important thing is that this is not about premature optimization, it is about refactoring code you don't fully understand.

blocks|key|800132|text|至少在我现在使用的编译器(gcc+4.2)上，它为您的第一个表达式生成的汇编代码使用了here描述的技巧。然后，它递减结果并使用条件代码来决定如何进行分支。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|800133|对于第二个，它会将其重写为基本上是newpos+!=+oldpos的内容|style|CODE|800134|你给出的两个表达在意思上略有不同。但无论哪种方式，我见过的大多数合理的编译器都会部署一些非常有趣的技巧来微优化代码。在这一点上，你很难超越编译器。您最好的选择是通常的建议:尝试这两个版本，分析代码，看看哪一个实际执行得更快。|800135|顺便说一句，如果您在第一个测试中使用abs(newpos+-+oldpos)+>=+1，它仍然会生成绝对值序列。这可能是因为假设2的补码系统，在减法中有溢出的可能性。例如，在我的机器上，abs(-2147483648+-+2147483647)给出了1，如果你在寻找2或更多的增量，那么它将无法通过测试，即使它们显然是完全不同的。编译器的优化器必须小心地保留这种行为，即使在边缘情况下也是如此。|800136|entityMap|0|LINK|mutability|MUTABLE|url|http://www-graphics.stanford.edu/~seander/bithacks.html#IntegerAbs^0|17|4|0|0|H|G|0|0|I|P|2L|T|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|D|3|E|5|6|7|X|8|@$A|Y|B|Z|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|11|8|@$A|12|B|13|F|G]|$A|14|B|15|F|G]]|9|@]|C|$]]|$1|L|3|-4|5|6|7|16|8|@]|9|@]|C|$]]]|M|$N|$5|O|P|Q|C|$R|S]]]]

At least on the compiler that I'm using at the moment (gcc 4.2), the assembly code that it generates for your first expression employs the trick described <a href="http://www-graphics.stanford.edu/~seander/bithacks.html#IntegerAbs" rel="nofollow noreferrer">here</a>. Then it decrements the result and uses the condition code to decide how to branch.

For your second, it rewrites it to something that's basically, <code>newpos != oldpos</code>

The two expressions that you gave are slightly different in meaning. But either way, most reasonable compilers that I've seen deploy some very interesting tricks to micro-optimize your code. You'd be hard pressed to outdo the compiler in this regard. Your best bet is the usual advice: try both versions, profile the code, and see which actually executes more quickly.

By the way, if you'd meant <code>abs(newpos - oldpos) >= 1</code> for the first test, it still generates the absolute value sequence. That's probably because of the possibility of overflow in the subtraction, assuming a two's complement system. On my machine, for example, <code>abs(-2147483648 - 2147483647)</code> gives 1 which would fail your test if you were looking for a delta of say, 2 or more instead even though they're clearly quite different. The compiler's optimizer has to be careful to preserve this kind of behavior even on edge cases.

I know- Premature optimization. 
But I've got code that's supposed to find out if a position is changed vs a cached position.

Current code is:

<pre><code>if(abs(newpos-oldpos) &gt; 1){
 .....
}
</code></pre>

Is it more efficient to use the following?

<pre><code>if(abs(newpos-oldpos) != 0){
 ....
}
</code></pre>

Why or why not? I'm currently debating it my head which is more readable and was wondering if there was a performance difference I was missing.

Efficency of Comparisons in C++? ( abs(X)>1 vs abs(x) != 0)

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

我知道-过早的优化。但是我的代码应该是用来判断一个位置和一个缓存的位置是否发生了变化。当前代码为：if(abs(newpos-oldpos) > 1){    .....}使用下面的代码会更有效吗？if(abs(newpos-oldpos) != 0){    ....}为什么或者为什么不？我现在正在讨论我的想法，它更具可读性，我想知道是否有我遗漏的性能差异。

问C++中的比较效率？( abs(X)>1 vs abs(x) != 0)
EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C++中的比较效率？( abs(X)>1 vs abs(x) != 0)EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C++中的比较效率？( abs(X)>1 vs abs(x) != 0)
EN