Question

为什么隐式投射甚至被允许？我的意思是隐含地将float强加给int有什么好处？没有显式强制转换可以使代码更易读，更容易调试吗？

Answer 1

回答：是的，这是一个例子

#include <stdio.h>

int main()
{
  unsigned int a=1;
  int b=-1;
  if(b>a)
     printf("-1 > 1 \n");
   else 
     printf("boring!\n");

return 0;
}

如果您执行此代码，您将获得

-1 > 1

这是由于变量b的隐式转换（b将转换为unsigned int并将-1转为4294976295 1）有时候会出现问题，所以为了让你和为同一个项目工作的程序员清楚地做出明确的演员是一个好习惯!!

Answer 2

问题：

为什么隐式投射甚至被允许？我的意思是什么是好处隐式地将浮点数转换为int？

C FAQ的维护者Steve Summit在tutorial中说：

默认转化规则有两个目的。一个人纯属自私在编译器的部分：它不想知道如何生成代码，例如，将浮点数添加到整数。该如果所有操作都在两个值上运行，编译器会更喜欢相同的类型：两个整数，两个浮点数等。（的确，很少有处理器具有添加浮点数的指令到整数;大多数都有添加两个整数或两个整数的说明浮点数。）默认转换的另一个目的是程序员的便利：“计算机和计算机”的心态编译器是愚蠢的，我们程序员必须指定所有内容令人难以忍受的细节''可以带得太远，这是合理的定义语言以便执行某些转换当它是明确的时，由编译器隐式地和自动地进行这样做是安全的。

问题2：

显式转换是否使得更易读和更容易调试码？

答案：

如上所述，这是隐式转换的发生方式显式转换“YES”增加了可读性。

Answer 3

首先：C ++中的大量隐式转换是由于历史原因，没有别的。我认为没有人会考虑他们都是个好主意。另一方面，有很多不同隐式转换的类型，其中一些几乎是必不可少的语言：如果您需要显式转换，您将不会喜欢它将MyType x;传递给一个MyType const&的函数;我很漂亮确定有一个共识，const转换添加const，比如这个，应该是隐含的。

关于尚未达成共识的转化：

几乎没有人似乎有无损转换的问题; int到long或float到double之类的内容。大多数人也似乎接受从整数类型到浮点的转换（例如 int到double），虽然在某些情况下这些可能会失去精确度。（例如int i = 123456789; float f = i;。）
在C ++ 98标准化过程中有一个建议弃用缩小转化次数，例如float到int。（作者）提议是Stroustrup;如果你不喜欢这样的转换，那你就进去了好公司。）它没有通过;我不知道究竟为什么，但我怀疑这是一个从C的传统中挣脱太多的问题。在C ++ 11中，在某些较新的构造中禁止这样的转换，像新的初始化序列。所以听起来像是有的一致认为这些隐含的转换并不是一个好主意，但他们不能因为害怕破坏代码而被删除打破了C的传统。（我知道不止一些人不喜欢someString += 3.14159;是法律声明的事实，在字符串的末尾添加一个ETX字符。）
bool的原始提案建议弃用所有将数字和指针类型转换为bool。这被删除了; 很快就会发现这个提案如果成功就不会通过像if ( somePointer )这样的东西（相对于 if ( somePointer != NULL )）非法。还有很大一部分考虑到这种转变的人（包括我自己）和不好的人，并且避免它们。

最后：编译器可以自由发出任何感觉的警告喜欢。如果市场坚持要求进行此类转换，编译器会实施它们（可能作为一种选择）。我怀疑了他们之所以不这样做是因为这些警告声名狼借初始实现产生太多警告。积分促销会带来许多无人想要的缩小转化消除：

char ch = '0' + v % 10;

例如，

涉及int到char转换（即。{ 变窄）;在C ++ 11中：

char ch{ '0' + v % 10 };

是非法的（但VC ++和g ++都接受它，g ++带有警告）。一世怀疑可以使用，禁止缩小转换率至少会必须对更广泛类型本身所致的情况做出例外积分推广，混合型算术和来源的案例表达式是一个编译时间常数，它适合＆＃34;在目标类型中。

Answer 4

显然，破坏旧代码会阻止新版本的语言（C和C ++）更改规则。所以问题是为什么在构思C时首先允许这样做。我理解，根本原因是C被建模为接近硬件，而硬件并没有（通常，从根本上）区分地址，整数和布尔类型。因此，像int i=10; while(i--) doSomething(i);或int *p, offset; ... if(p) doSomethingElse(p+offset);这样的代码几乎可以直接转换为机器代码。事实上，它离宏汇编程序不远，大多数差异都是函数调用的细节。在我看来，它也非常易读。任何额外的强制转换或显式比较都会损害逻辑的简单可见性。但是，这当然是品味和编程社会化的问题。

然后是的，70年代没有的经验表明，一些隐含的转换是错误的来源。如果K＆amp; R再次设想C，他们可能会改变一些（几乎没有）的东西。尽管我们必须处理编译器警告，但世界仍然存在。

隐式铸造被认为是一个坏概念吗？

4 个答案: