blocks|key|1821230|text|您希望它们都使用IEEE+754标准。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1821231|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/IEEE_floating_point^0|8|A|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You want them both to be using the <a href="http://en.wikipedia.org/wiki/IEEE_floating_point" rel="nofollow">IEEE 754 standard</a>.

blocks|key|3141014|text|摘要:编译器通常不支持这一点，您将很难用更高级别的语言来完成它，并且您需要使用一个与所有目标平台相同的数学库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3141015|C和C%2B%2B语言标准允许在浮点操作中实现相当大的灵活性。许多C和C%2B%2B浮点操作不需要遵循IEEE754-2008标准，这对许多程序员来说可能是直观的。|3141016|即使是许多C和C%2B%2B实现也不能很好地支持遵循IEEE754-2008标准。|3141017|数学库实现是一个特殊的问题。没有任何普通库(商业上可用的或广泛使用的具有已知有界运行时的开放源代码)为所有标准数学函数提供正确的四舍五入结果。(在某些函数上得到正确的数学是一个非常困难的问题。)|3141018|然而，sqrt相对简单，应该在一个质量合理的库中正确返回圆角结果。(我无法为Microsoft实现提供担保。)在您显示的代码中，更有可能的问题是编译器在计算表达式时选择使用浮动点的不同精度。|offset|length|style|CODE|3141019|您可以在不同的编译器中使用不同的开关，要求它们遵守有关浮点行为的某些规则。这些可能足以使基本操作按预期执行。否则，汇编语言是访问定义良好的浮点操作的一种方法。但是，除非提供公共库，否则不同平台的库例程的行为将有所不同。这包括数学库例程(如pow)和fprintf、fscanf、strtof等例程中的转换。因此，您必须为您所依赖的每个例程找到一个设计良好的实现，它在您所针对的所有平台上都得到了支持。(它必须设计得很好，因为它在所有平台上都提供相同的行为。从数学上讲，它可能有些不准确，只要它在您的应用程序所能容忍的范围内。)|3141020|entityMap^0|0|0|0|0|3|4|0|3B|3|3G|7|3O|6|3V|6|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|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@$J|W|K|X|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@$J|Z|K|10|L|M]|$J|11|K|12|L|M]|$J|13|K|14|L|M]|$J|15|K|16|L|M]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|Q|$]]

Summary: This is generally not supported by compilers, you will have a tough time doing it in a higher-level language, and you will need to use one math library common to all your target platforms.

The C and C++ language standards allow implementations a considerable amount (too much) of flexibility in floating-point operations. Many C and C++ floating-operations are not required to adhere to the IEEE 754-2008 standard in the way that might be intuitive to many programmers.

Even many C and C++ implementations do not provide good support for adhering to the IEEE 754-2008 standard.

Math library implementations are a particular problem. There does not exist any normal library (commercially available or widely-used open source with a known-bounded run-time) that provides correctly rounded results for all standard math functions. (Getting the mathematics right on some of the functions is a very difficult problem.)

<code>sqrt</code>, however, is relatively simple and should return correctly rounded results in an library of reasonable quality. (I am unable to vouch for the Microsoft implementation.) It is more likely the particular problem in the code you show is the compiler’s choice to use varying precisions of floating-point while evaluating expressions.

There may be various switches you can use with various compilers to ask them to conform to certain rules about floating-point behavior. Those may be sufficient for getting elementary operations to perform as expected. If not, assembly language is a way to access well-defined floating-point operations. However, the behavior of library routines will be different between platforms unless you supply a common library. This includes both math library routines (such as <code>pow</code>) and conversions found in routines such as <code>fprintf</code>, <code>fscanf</code>, <code>strtof</code>. You must therefore find one well-designed implementation of each routine you rely on that is supported on all of the platforms you target. (It must be well-designed in the sense that it provides identical behavior on all platforms. Mathematically, it could be somewhat inaccurate, as long as it is within bounds tolerable for your application.)

blocks|key|3141048|text|使用我的4.6.3编译器，它生成以下代码：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3141049|main:
.LFB104:
++++.cfi_startproc
++++subq++++$8,+%25rsp
++++.cfi_def_cfa_offset+16
++++movl++++$1063434539,+%25esi
++++movl++++$.LC1,+%25edi
++++movsd+++.LC0(%25rip),+%25xmm0
++++movl++++$1,+%25eax
++++call++++printf
++++xorl++++%25eax,+%25eax
++++addq++++$8,+%25rsp
++++.cfi_def_cfa_offset+8
++++ret
++++.cfi_endproc

.LC0:
++++.long+++1610612736
++++.long+++1072453413|code-block|syntax|javascript|3141050|请注意，在此代码中执行的计算为零，只是将各种常量存储在寄存器中。|3141051|我没有Visual编译器，所以我不知道它会产生什么。|3141052|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

With my 4.6.3 compiler it generates this code:

<pre><code>main:
.LFB104:
 .cfi_startproc
 subq $8, %rsp
 .cfi_def_cfa_offset 16
 movl $1063434539, %esi
 movl $.LC1, %edi
 movsd .LC0(%rip), %xmm0
 movl $1, %eax
 call printf
 xorl %eax, %eax
 addq $8, %rsp
 .cfi_def_cfa_offset 8
 ret
 .cfi_endproc

.LC0:
 .long 1610612736
 .long 1072453413
</code></pre>

Note that there is ZERO calculations performed in this code, just storing various constants in registers. 

I haven't got a Visual stdudio compiler, so I don't know what that produces.

blocks|key|745123|text|GCC编译器实现了所谓的严格混叠语义，这依赖于这样一个事实:在C和C%2B%2B中，通过指针转换执行类型双关通常是非法的(只有少数例外)。您的代码包含多个违反严格别名语义要求的行为。因此，完全符合逻辑的是，将严格的混叠语义和优化相结合可能会在GCC+(或任何其他编译器)中产生完全出乎意料的、看似不合逻辑的结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|745124|最重要的是，在sqrt中没有什么不寻常的地方，在不同的实现中产生的结果略有不同。|offset|length|style|CODE|745125|entityMap^0|0|7|4|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

GCC compiler implements so called strict-aliasing semantics, which relies on the fact that in both C and C++ it is generally illegal to perform type-punning through pointer conversions (with few exceptions). Your code contains multiple violations of the requirements of strict-aliasing semantics. So, it is perfectly logical to expect that combination of strict-aliasing semantics and optimizations might produce completely unexpected and seemingly illogical results in GCC (or any other compiler, for that matter).

On top of that, there would be nothing unusual in <code>sqrt</code> producing slightly different results in different implementations.

blocks|key|745197|text|C允许以浮点的精度或更高的精度进行中间计算。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|745198|如果只使用float进行所有计算，则windows结果与GCC匹配。|offset|length|style|CODE|745199|当所有计算都被编码为float时，GCC的计算得到了不同(更准确)的结果，但中间结果允许为双倍或长倍。|745200|因此，即使所有内容都符合IEEE+754标准，控制允许的中间计算也会产生影响。|745201|编辑我认为以上并不是真正回答OP声明的问题，而是关心一般的FP问题。以下是我认为最能解释这种差异的原因。|745202|MS网络sqrt|745203|我怀疑不同之处在于，在windows编译中，它处于C%2B%2B模式，因此称为float+sqrt(float)。在gcc中，它是C模式，sqrt(x1)称为double+sqrt(double)。|BOLD|745204|如果是这样的话，确保windows中的C代码是在C模式下编译的，而不是C%2B%2B。|745205|int+main()+{
++{
++++volatile+float+f1;
++++float+f2;
++++double+d1;
++++int+xm+=+0x3f18492a;
++++f1+=+*(float*)+&xm;
++++f2+=+*(float*)+&xm;
++++d1+=+*(float*)+&xm;
++++f1+=+sqrtf(f1);
++++f1+=+f1+%2B+1.0f;
++++f1+=+f1+/+2.0f;
++++printf("f1++%250.17e+%25a+%2508X\n",+f1,+f1,+*(int*)&f1);
++++f2+=+(sqrt(f2)+%2B+1)+/+2.0;
++++printf("f2++%250.17e+%25a+%2508X\n",+f2,+f2,+*(int*)&f2);
++++d1+=+(sqrt(d1)+%2B+1)+/+2.0;
++++printf("d1++%250.17e+%25a\n",+d1,+d1);
++++return+0;
++}

f1++8.85637879371643066e-01+0x1.c57254p-1+3F62B92A
f2++8.85637938976287842e-01+0x1.c57256p-1+3F62B92B
d1++8.85637911452129889e-01+0x1.c572551391bc9p-1|code-block|syntax|javascript|745206|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/f1xa99e6%2528v=vs.90%2529.aspx^0|0|5|5|0|A|5|0|0|0|0|8|0|0|B|7|Z|H|1I|3|23|J|1T|8|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|18|8|@$D|19|E|1A|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1B|8|@$D|1C|E|1D|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1E|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1F|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1G|8|@]|9|@$D|1H|E|1I|1|1J]]|A|$]]|$1|P|3|Q|5|6|7|1K|8|@$D|1L|E|1M|F|R]|$D|1N|E|1O|F|R]|$D|1P|E|1Q|F|R]|$D|1R|E|1S|F|R]|$D|1T|E|1U|F|G]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1V|8|@]|9|@]|A|$]]|$1|U|3|V|5|W|7|1W|8|@]|9|@]|A|$X|Y]]|$1|Z|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]]|10|$11|$5|12|13|14|A|$15|16]]]]

C allows intermediate calculation to occurs at the floating point's precision or at a higher one.

The windows result matches the GCC if all calculations occurs using only using <code>float</code>.

The GCC calculation obtains the different (and more accurate) result when all calculations are coded as <code>float</code>, but are allowed to go to double or long double for intermediate results.

So even if everything is IEEE 754 compliant, controlling the allowed intermediate calculations has an effect.

[Edit] I do not think the above really answers the OP stated issue, but is a concern for general FP issues. It is the below, that I think best explains the difference.

<a href="http://msdn.microsoft.com/en-us/library/f1xa99e6%28v=vs.90%29.aspx" rel="nofollow">MS dev network sqrt</a>

I suspect the difference was that in the windows compilation, it was in C++ mode, thus the <code>sqrt(x)</code> called float sqrt(float). In gcc, it was in C mode and <code>sqrt(x1)</code> called double sqrt(double). 
If this is the case, insure C code in windows is compiled in C mode and not C++.

<pre><code>int main() {
 {
 volatile float f1;
 float f2;
 double d1;
 int xm = 0x3f18492a;
 f1 = *(float*) &amp;xm;
 f2 = *(float*) &amp;xm;
 d1 = *(float*) &amp;xm;
 f1 = sqrtf(f1);
 f1 = f1 + 1.0f;
 f1 = f1 / 2.0f;
 printf("f1 %0.17e %a %08X\n", f1, f1, *(int*)&amp;f1);
 f2 = (sqrt(f2) + 1) / 2.0;
 printf("f2 %0.17e %a %08X\n", f2, f2, *(int*)&amp;f2);
 d1 = (sqrt(d1) + 1) / 2.0;
 printf("d1 %0.17e %a\n", d1, d1);
 return 0;
 }

f1 8.85637879371643066e-01 0x1.c57254p-1 3F62B92A
f2 8.85637938976287842e-01 0x1.c57256p-1 3F62B92B
d1 8.85637911452129889e-01 0x1.c572551391bc9p-1
</code></pre>

blocks|key|745235|text|Visual编译器倾向于生成使用旧的x87+FPU(*)的指令，但它在可执行文件的开头生成代码，以将FPU设置为double格式的精度。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|745236|GCC还可以生成使用旧的x87+FPU的指令，但是当生成x86-64代码时，默认情况是使用SSE2。在Macs上，默认情况下即使在32位的情况下也要使用SSE2，因为所有的英特尔Mac都有SSE2。当GCC为387生成指令时，not将FPU的精度设置为double格式，以便以80位双扩展格式进行计算，然后在分配时舍入到double。|BOLD|745237|因此：|745238|如果只使用double计算，Visual应该生成一个精确计算类型的程序，因为它始终是double(**)。如果GCC方面使用-msse2+-mfpmath=sse，那么GCC也会生成符合doubles精度的代码，这一次是使用SSE2指令。计算应该是匹配的。|ordered-list-item|745239|或者，如果您让GCC和Visual同时发出SSE2指令，那么计算也应该匹配。我不熟悉Visual，但开关可能是/arch:SSE2。|745240|这并不能解决数学库的问题，这确实是一个未解决的问题。如果您的计算涉及三角函数或其他函数，则必须使用相同的库作为双方项目的一部分。我推荐CRlibm。不太精确的库也可以，只要它是同一个库，并且它遵守上述约束(只使用double或两边都使用SSE2编译)。|745241|(*)可能有一种方法可以指示它生成SSE2指令。如果你找到它，使用它:它将解决你的特殊问题。|745242|(**)无穷大和次法线的模例外。|745243|entityMap|0|LINK|mutability|MUTABLE|url|http://lipforge.ens-lyon.fr/www/crlibm/^0|1K|6|0|35|3|3I|6|4G|6|0|0|5|6|16|6|1Q|J|2L|6|0|1J|A|0|2Y|6|1V|6|0|0|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@$9|14|A|15|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|16|8|@$9|17|A|18|B|H]|$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|I|3|J|5|6|7|1D|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|1E|8|@$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]|$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|N|3|O|5|M|7|1N|8|@$9|1O|A|1P|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1Q|8|@$9|1R|A|1S|B|C]]|D|@$9|1T|A|1U|1|1V]]|E|$]]|$1|R|3|S|5|6|7|1W|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|1X|8|@]|D|@]|E|$]]|$1|V|3|-4|5|6|7|1Y|8|@]|D|@]|E|$]]]|W|$X|$5|Y|Z|10|E|$11|12]]]]

The Visual Studio compiler tends to generate instructions that use the old x87 FPU(*), but it generates code at the beginning of the executable to set the FPU to the precision of the <code>double</code> format.

GCC can also generate instructions that use the old x87 FPU, but when generating x86-64 code, the default is to use SSE2. On Mac OS X, the default is to use SSE2 even in 32-bit since all Intel Macs have SSE2. When it generates instruction for the 387, GCC does not set the precision of the FPU to the <code>double</code> format, so that computations are made in the 80-bit double-extended format, and then rounded to <code>double</code> when assigned.

As a consequence:

<ol>
<li>If you use only <code>double</code> computations, Visual Studio should generate a program that computes exactly at the precision of the type, because it is always <code>double</code>(**). And if on the GCC side you use <code>-msse2 -mfpmath=sse</code>, you can expect GCC to also generate code that computes at the precision of <code>double</code>s, this time by using SSE2 instructions. The computations should match.</li>
<li>Or if you make both GCC and Visual Studio emit SSE2 instructions, again, the computations should match. I am not familiar with Visual Studio but the switch may be <code>/arch:SSE2</code>.</li>
</ol>

This does not solve the problem with math libraries, which is indeed an unsolved problem. If your computations involve trigonometric or other functions, you must use the same library as part of your project on both sides. I would recommend <a href="http://lipforge.ens-lyon.fr/www/crlibm/" rel="nofollow">CRlibm</a>. Less accurate libraries are fine too as long as it's the same library, and it respects the above constraints (using only <code>double</code> or compiled with SSE2 on both sides).

(*) There may be a way to instruct it to generate SSE2 instructions. If you find it, use it: it will solve your particular problem.

(**) modulo exceptions for infinities and subnormals.

blocks|key|1821852|text|如果您有更改语言的自由，可以考虑使用带有"strictfp“的Java。Java语言规范为严格的模式下操作顺序、舍入等提供了非常精确的规则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1821853|精确匹配跨实现的结果是严格的Java标准的目标之一。这不是C%2B%2B标准的目标。|1821854|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|$]]

If you have freedom to change languages, consider using Java with "strictfp". The Java language specification gives very precise rules for order of operations, rounding etc. in strictfp mode.

Exactly matching results across implementations is an objective of the Java standard for strictfp mode. It is not an objective for the C++ standards.

blocks|key|3141348|text|IEEE+754指定计算可以以比存储在内存中的精度更高的精度处理，然后在写入内存时舍入。这导致了许多问题，如您看到的问题。简而言之，该标准并不保证在所有硬件上执行的相同计算将返回相同的答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3141349|如果要计算的值放在更大的寄存器上，则进行一次计算，然后将值从寄存器移回内存，结果在那里被截断。然后，可以将其移回更大的寄存器，以便进行另一次计算。|3141350|另一方面，如果在将值移回内存之前，所有计算都是在较大的寄存器上完成的，则会得到不同的结果。您可能需要拆解代码来查看在您的情况下发生了什么。|3141351|对于浮点工作，重要的是了解您在最终答案中需要多少精度，以及您所选择的变量的精度(注意单词的两种用法)可以保证有多高的精度，并且永远不要比保证的精度更高。|3141352|最后，当您比较结果(对于任何浮点工作都是这样)时，您无法查找确切的匹配，您可以确定所需的精度，并检查两个值之间的差异是否小于所需的精度。|3141353|回到实际情况，Intel处理器有80位寄存器用于浮点计算，即使您指定了浮点数(通常为32位)(但并不总是这样)。|3141354|如果您想玩得开心，试着在编译器中打开各种优化和处理器选项，比如SSE，看看得到什么结果(以及反汇编程序的结果)。|3141355|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

The IEEE 754 specifies that computations can be processed at a higher precision than what is stored in memory then rounded when written back to memory. This causes many issues such as the one you see. In short, the standard does not promise that the same computation carried out on all hardware will return the same answer. 

If the value to be computed on is placed on a larger register then one computation is done and then the value is moved off of the register back to memory the result is truncated there. It could then be moved back on to the larger register for another computation. 

On the other hand if all the computations are done on the larger register before the value is moved back to memory you will get a different result. You may have to disassemble the code to see what's happening in your case. 

With float point work it's important to understand how much precision you need in the final answer and how much precision you are guaranteed to have by the precision (note the two uses of the word) of the variables you choose and never expect anymore precision than you are guaranteed. 

In the end when you are comparing results (this is true of any floating point work) you can not look for exact matches, you determine the precision that you require and you check that the difference between two values is less than the precision you require. 

Getting back to practicalities, the Intel processors have 80 bit registers for floating point computations that may be used even though you've specified float which is typically 32-bit (but not always). 

If you want to have fun try turning on various optimizations and processor options like SSE in your compiler and see what results you get (as well as what comes out of the disassembler).

I'm trying to solve a cross-platform issue that's cropping up and I'm not sure quite how to go about it. Here's a demonstration program:

<pre><code>#include &lt;cmath&gt;
#include &lt;cstdio&gt;

int main()
{
 int xm = 0x3f18492a;
 float x = *(float*)&amp;xm;
 x = (sqrt(x) + 1) / 2.0f;
 printf("%f %x\n", x, *(int*)&amp;x);
}
</code></pre>

The output on Windows when compiled in VS2010 is:

<code>0.885638 3f62b92a</code>

The output when compiled with GCC 4.8.1 <a href="http://ideone.com/bORBP1" rel="noreferrer">(ideone.com sample) </a>is:

<code>0.885638 3f62b92b</code>

These small mismatches end up ballooning into a serious problem over the course of a program that needs to run identically on multiple platforms. I'm not concerned so much about "accuracy" as that the results match each other. I tried switching the <code>/fp</code> mode in VS to <code>strict</code> from <code>precise</code>, but that doesn't seem to fix it. 

What other avenues should I look at to make this calculation have the same result on both platforms?

UPDATE: Interestingly, if I change the code like this, it matches across the platforms:

<pre><code>#include &lt;cmath&gt;
#include &lt;cstdio&gt;

int main()
{
 int xm = 0x3f18492a;
 float x = *(float*)&amp;xm;
 //x = (sqrt(x) + 1) / 2.0f;
 float y = sqrt(x);
 float z = y + 1;
 float w = z / 2.0f;
 printf("%f %x %f %x %f %x %f %x\n", x, *(int*)&amp;x, y, *(int*)&amp;y, z, *(int*)&amp;z, w, *(int*)&amp;w);
}
</code></pre>

I'm not sure it's realistic, however, to be walking through the code and changing all floating point operations like this!

Floating point mismatch between compilers (Visual Studio 2010 and GCC)

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

我正试图解决一个跨平台的问题，我不知道该如何解决。下面是一个演示程序：#include <cmath>#include <cstdio>int main(){ int xm = 0x3f18492a; float x = *(float*)&xm; x = (sqrt(x) + 1) / 2.0f; ...

问编译器之间的浮点不匹配(Visual 2010和GCC)
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问编译器之间的浮点不匹配(Visual 2010和GCC)EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问编译器之间的浮点不匹配(Visual 2010和GCC)
EN