Merge pull request #2486 from KayGuoWhu/master

[Translated]20150124 Why does C++ promote an int to a float when a float cannot represent all int values

sources/talk/20150124 Why does C++ promote an int to a float when a float cannot represent all int values.md

@@ -1,44 +0,0 @@
-translating by KayGuoWhu
-Why does C++ promote an int to a float when a float cannot represent all int values?
----------
-
-#Q:
-
-Say I have the following:
-
-```C
-int i = 23;
-float f = 3.14;
-if (i == f) // do something
-```
-
-The i will be promoted to a float and the two float numbers will be compared, but can a float represent all int values? Why not promote both the int and the float to a double?
-
-#A:
-
-When `int` is promoted to `unsigned` in the integral promotions, negative values are also lost (which leads to such fun as `0u < -1` being true).
-
-Like most mechanisms in C (that are inherited in C++), the usual arithmetic conversions should be understood in terms of hardware operations. The makers of C were very familiar with the assembly language of the machines with which they worked, and they wrote C to make immediate sense to themselves and people like themselves when writing things that would until then have been written in assembly (such as the UNIX kernel).
-
-Now, processors, as a rule, do not have mixed-type instructions (add float to double, compare int to float, etc.) because it would be a huge waste of real estate on the wafer -- you'd have to implement as many times more opcodes as you want to support different types. That you only have instructions for "add int to int," "compare float to float", "multiply unsigned with unsigned" etc. makes the usual arithmetic conversions necessary in the first place -- they are a mapping of two types to the instruction family that makes most sense to use with them.
-
-From the point of view of someone who's used to writing low-level machine code, if you have mixed types, the assembler instructions you're most likely to consider in the general case are those that require the least conversions. This is particularly the case with floating points, where conversions are runtime-expensive, and particularly back in the early 1970s, when C was developed, computers were slow, and when floating point calculations were done in software. This shows in the usual arithmetic conversions -- only one operand is ever converted (with the single exception of `long/unsigned int`, where the `long` may be converted to `unsigned long`, which does not require anything to be done on most machines. Perhaps not on any where the exception applies).
-
-So, the usual arithmetic conversions are written to do what an assembly coder would do most of the time: you have two types that don't fit, convert one to the other so that it does. This is what you'd do in assembler code unless you had a specific reason to do otherwise, and to people who are used to writing assembler code and do have a specific reason to force a different conversion, explicitly requesting that conversion is natural. After all, you can simply write
-
-```C
-if((double) i < (double) f)
-```
-
-It is interesting to note in this context, by the way, that `unsigned` is higher in the hierarchy than `int`, so that comparing `int` with `unsigned` will end in an unsigned comparison (hence the `0u < -1` bit from the beginning). I suspect this to be an indicator that people in olden times considered `unsigned` less as a restriction on `int` than as an extension of its value range: We don't need the sign right now, so let's use the extra bit for a larger value range. You'd use it if you had reason to expect that an `int` would overflow -- a much bigger worry in a world of 16-bit ints.
-
-----
-via:[stackoverflow](http://stackoverflow.com/questions/28010565/why-does-c-promote-an-int-to-a-float-when-a-float-cannot-represent-all-int-val/28011249#28011249)
-
-作者：[wintermute][a]
-译者：[译者ID](https://github.com/译者ID)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
-
-[a]:http://stackoverflow.com/users/4301306/wintermute

translated/talk/20150124 Why does C++ promote an int to a float when a float cannot represent all int values.md

@@ -0,0 +1,43 @@
+既然float不能表示所有的int，那为什么在类型转换时C++将int转换成float？
+---------
+
+#问题：
+
+代码如下：
+
+```C
+int i = 23;
+float f = 3.14;
+if (i == f) // 执行某段代码
+```
+
+编译器会将i转换成float类型，然后比较这两个float的大小，但是float能够表示所有的int吗？为什么没有将int和float转换成double类型进行比较呢？
+
+#回答：
+
+在整型数的演变中，当`int`变成`unsigned`时，会丢掉负数部分（有趣的是，这样的话，`0u < -1`就是对的了）。
+
+和C语言中的大部分机制（在C++中得到继承）一样，就硬件操作而言，常见的算术转换应该简明易懂。C语言的发明者精通他们所使用机器上的汇编语言，他们编写的C语言对他们和像他们一样编写程序的人有直接的意义，直到使用汇编语言编写（诸如UNIX内核）的程序时。
+
+现如今，一般来说，处理器并不具有混合类型的指令系统（如float和double相加、比较int和float，诸如此类），因为如果这样做造成芯片晶圆的巨大浪费——如果你想支持更多不同的类型，你不得不实现更多的操作码。然而，在实际中，你只有实现"add int to int"、"compare float to float"和"multiply unsigned with unsigned"等功能的常见指令，这使得优先进行算术转换变得很有必要——它们是指令系统中两种类型的映射关系，它们中的大部分很有用处。
+
+从习惯编写低级别机器代码的编程人员的角度来说，如果有了混合类型，那么在一般情况下最有可能使用的汇编指令就是那些只需要进行最少类型转换的指令。其中，有一种特殊情况就是浮点数的转换，特别是在20世纪70年代早期，当时C语言正在被开发，计算机运行速度很慢，而浮点数的计算是通过软件完成的，所以进行转换的成本很高。这拖慢了常用算术运算的转换开发——当时只有一种操作数实现了转换（这个例外就是long到unsigned int的转换，这种转换没有任何要求，在大部分机器上都可以进行。当然并不是全部，因为总有例外情况）。
+
+所以，编写常用的算术转换是为了完成汇编程序员在大部分时间需要做的事情：即有两种不匹配的类型，将一种转换成另一种。这也就是汇编代码所做的事情，除非有特别原因需要进行其它类型转换。对于那些习惯编写汇编代码的人来说，除非是特殊需要，才会被迫去编写一种不同的类型转换。显然，这种情况下提出编写转换是很自然的事情。虽然，你可以简单地写成这样
+
+```C
+if((double) i < (double) f)
+```
+
+顺便提一下，在这个问题中有趣的是，`unsigned`的优先级高于`int`，所以把`int`和`unsigned`进行比较时，最终进行的是unsigned类型的比较（开头提到的`0u < -1`就是这个道理）。我猜测这可能是在早些时候（计算机发展初期），当时的人们认为`unsigned`比`int`在所表示的数值范围上受到的限制更小：现在还不需要符号位，所以可以使用额外的位来表示更大的数值范围。如果你觉得`int`可能会溢出，那么就使用unsigned好了——在使用16位表示的ints时这个担心会更明显。
+
+----
+via:[stackoverflow](http://stackoverflow.com/questions/28010565/why-does-c-promote-an-int-to-a-float-when-a-float-cannot-represent-all-int-val/28011249#28011249)
+
+作者：[wintermute][a]
+译者：[KayGuoWhu](https://github.com/KayGuoWhu)
+校对：[校对者ID](https://github.com/校对者ID)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
+
+[a]:http://stackoverflow.com/users/4301306/wintermute