内联运营商是否良好？

在C++中内联运算符和其他方法是否有区别？我已经搜索过它，但它并不是一个常见的问题，正如我所看到的。有没有人有强烈的理由使用它或避免？注：显然，我的意思是内联运营商，当他们小。内联运营商是否良好？

2013-01-09 JalalJaberi

那么内联达不到你，但是编译器，除非你使用特定的编译器的东西。所以C++的答案是：无所谓，无法控制它。 – GManNickG

@GManNickG：这应该是一个答案，而不是评论！ –

@ K-ballo：那么，这将需要付出努力，然后解释'inline'关键字如何不实际控制内联和meh，我已经懒惰了。 :) – GManNickG

尽管这个可能在编译器之间会有所不同，但我期望从编译器的角度来看，运算符只是另一个有点不同寻常的名称的函数，它允许源代码的语法看起来有点不同。

尽管如此，由当时的编译运行的代码生成器的一部分，我希望重载运算符和另一个函数（即做了同样的事情）已经消失任何区别。

因此，它声明为inline或类定义体内定义它会有一样多（少，这取决于你的观点）与运算符重载任何其他功能。我通常希望这种效果在两种情况下都非常小 - 至少在启用优化时，大多数编译器几乎忽略了关键字inline，并自行决定如何自行扩展内联（以及不应该）。

请注意，有一种编译器不能忽略关键字inline - 对“一个定义规则”有一些必须遵守的特殊修改，而不管函数是否实际上是以内联方式扩展的。

来源

2013-01-09 00:52:59

运营商超载**只是**另一个功能，没有区别 –

@ K-ballo：从标准的角度来看，你显然是正确的。我希望从编译器的观点来看它是正确的 - 但是编译器*可以根据是否有操作符超载来应用关于内联的不同规则（尽管在实践中我会惊讶地发现它）。 –

编译器也可以根据任何其他条件应用不同的内联规则，比如函数接受的参数个数，或者其名称是否与特定的模式匹配。重载操作符在这方面没有什么特别之处。 – Wyzard

您可以使用inline关键字建议给编译器一个函数内联。

编译器没有义务服从该请求。

运营商是相似的 - 他们可能会或可能不会被内联。

由于编译器不能强制内联有可能是使用或者避免使用内联提示不强的原因。因为这就是他们的全部：提示。

在Visual C++中您可以使用关键字__forceinline强制内联，结果是更大的代码和性能的潜在损失。在精心设计的系统中，消除选项（通过强制执行）常常导致性能较差，这是很常见的。即使您使用此关键字，也不是每个函数都可以成功内联。

GCC内联讨论here。

来源

2013-01-09 00:56:33 Richard

“结果是更大的代码和潜在的性能损失”[或者它可能是更小的代码。或更快]（http://www.parashift.com/c++-faq/inline-and-perf.html）（我承认，链接的网页错误地假定编译器始终将内联函数标记为“inline”） –

正如其他人提到的，如果编译器“内联”方法通常不是您的名义，关于inline关键字的使用和编译器的优化策略。

所以我觉得更重要的方面是头文件的可读性和operator方法可能出现套例如算术操作实现，其中可以使用简单的转换来构建它们。因此，如果我不得不查看这样的头文件，我希望看到逻辑上相关的操作符方法签名集合，以获得有关适用与否的概述。

一个很简单的例子是operator==()和operator!=()实施：

class A 
{ 
public: 

    // Equality tests 
    //----------------------------------------------------------------------- 

    // This may involve some mor complex code that'll look ugly here 
    bool operator==(const A& rhs) const; 

    // Fine, this is a one liner. Code appears 'inline' (and is likely to be 
    // chosen for inlining by the compiler, no matter if inline keyword or not) 
    bool operator!=(const A& rhs) const { return !A::operator==(rhs); } 
};

来源

2013-01-09 01:27:29

内联运营商是否良好？

回答

相关问题