C++ 我需要.CPP文件吗？仅使用标题并使所有内容内联？

特别是GCC 4.6.1

我知道CPP文件用于将接口与实现分开；那现在不感兴趣

现在来看，我看不出有任何理由不使用头和所有内联函数

---

性能是一个问题，但我不认为这种方法会让事情变得更慢。我不想让通常内联的关键部分变得更慢，因为所有内容都是内联的。如果有道理的话。

以下是一些不这样做的原因：

• 无包封；“内部”方法对整个程序可见
• 命名空间污染（导致命名冲突或程序员错误）
• 依赖问题；要确保所有东西都按正确的顺序申报变得更加困难
• 增加编译时间

---

除了性能和内联之外，还有一些事情你不能只使用头，比如类的

静态

字段

也就是说，

STL

中的大多数（如果不是全部的话）和大部分

Boost

一样，都只是标题

---

至于内联方法/函数，这并不重要。编译器比您更清楚该做什么，可能会忽略

inline

关键字（使函数非内联），或者相反，即使函数未声明为内联函数，也会进行内联函数调用。

如果所有函数都是“内联”的，那么您的二进制文件将更大，这可能会导致性能降低。您应该只内联非常小且经常调用的函数。

主要问题是编译时间，真的

如果所有内容都包含在单个“主”编译单元中，那么如果更改单个文件中的单个字符，则必须重新编译所有内容

另一方面，完全重建很可能比使用多个编译单元更快（在这种情况下，相同的头必须被编译多次，链接器将有更多的工作要做。使用单个编译单元，每个头只需要处理一次，链接器的工作非常简单）

对于多个.cpp文件，您可以对其中一个文件进行更改，只需重新编译该文件

但有几个流行的库只是标题。这绝对是可行的

性能方面，它应该相同或更快。您可以让编译器完全了解您的整个代码，这意味着它可以轻松地跨函数调用进行优化，并内联任何它喜欢的内容

请注意，您从未强制编译器内联。

inline

关键字（以及其他具有相同效果的技巧）不会告诉编译器“这必须是内联的”。但是，通过抑制一个定义规则（ODR），它们允许您将一个定义包含到多个编译单元中，因此如果编译器选择内联，它将更容易内联

---

但这意味着您不必担心所有内容都被内联。编译器只会尽可能多地内联。

将所有源文件连接到一个巨大的源文件中，这是发布版本的常见技巧。。。GCC有一个

-fwhole程序

，可以在这种情况下实现更彻底的优化。新的

-flto

在没有人工干预的情况下基本上做相同的事情。不用太担心，编写你的程序，这样下一个人就可以理解并继续。从技术上讲，编译器根本不关心头文件和实现文件——它们是C文件，有些包含声明，有些包含定义。但是内联并不能提高性能——编译器对此相当谨慎是有原因的（例如，它会使缓存变得杂乱无章）。您认为这会给您带来什么好处？1。封装——这根本不应该是个问题。看见2.要解决这个问题，只需在不同的名称空间中编写代码…@user1071136：我不是在说安全性。然后呢？如果一个方法是

private

，那么它是否可见并不重要，除非您关心安全性。否？@user1071136：我说的是提供定义良好的接口，而不是安全性。也许我的意思是“可接近”而不是“可见”。并非所有函数都是成员函数……您应该让编译器来决定。编译器的内联优化和

inline

关键字之间存在差异。将所有函数标记为内联并不意味着所有函数都将内联。