假设一个有大约 50,000 个不同的.cpp文件。
每个.cpp文件只包含一个类，其中包含大约 1000 行代码（代码本身并不复杂——涉及对矩阵和向量的内存操作——即，不使用特殊库）。
我需要构建一个项目（在Linux环境中），该项目必须导入和使用所有这 50,000 个不同的.cpp文件。
我想到了几个问题：
.so文件（编译后的扩展）并让主程序将它们一个一个导入，或者将这 50,000 个不同的.cpp文件合并到一个大 .cpp 文件中，然后处理？哪种方法会更快/更有效？非常感谢任何见解。
没有答案，只有建议。
就在你面前：你真正想做什么？您是否尝试从不同的源文件创建代码库？或者那是一个可执行文件？你真的编写了那么多 .cpp 文件吗？
50,000 个源文件很好……一个大型项目。您是否尝试在所有文件中做一些共同的事情（例如，每个源文件都代表一个资源、记录、图像或独特的东西）。或者它只是 50K 不同的代码文件？
您的大部分编译时间不会基于每个源文件的大小。它将基于每个 cpp 文件将引入的头文件（以及它们包含的头）的数量。头文件虽然通常不包含实现，只是声明，但必须经过编译过程。代码库中的冗余标头会减慢您的构建时间。
这种规模的大型项目使用预编译的头文件。您可以将所有常用的头文件包含在一个头文件（common.h）中并构建 common.h。然后所有其他源文件只包含“common.h”。编译器可以配置为在看到每个源的#include "common.h" 时自动使用已编译的头文件。
您可以从“.cpp”构建每个目标文件，让“.h”文件有很多（我的意思是很多）前向声明 - 所以当您更改.h文件时，它不需要重新编译程序的其余部分。通常，函数/方法需要其参数中的对象名称或它要返回的内容。如果它需要其他细节 - 是的，它需要被包括在内。
请买一本 Scott Myers 的书——对你有很大帮助。
哦 - 当试图吃一个大蛋糕时 - 把它分开。切片更易于管理。
(i) 决定这一点的因素太多了，即使是近似值也是不可能的。编译可以是内存、cpu 或硬盘驱动器。文件的复杂性很重要（根据您的描述，您的复杂性很低）。
(ii) 这样做的典型方法是制作一个库并让系统找出链接或加载。您可以选择静态或动态链接。
静态链接
假设您使用的是 gcc，这将如下所示：
g++ -c file1.cpp -o file1.o
g++ -c file2.cpp -o file2.o
...
g++ -c filen.cpp -o filen.o
ar -rc libvector.a file1.o file2.o ... filen.o
然后，当您构建自己的代码时，您的最终链接如下所示：
g++ myfile.cpp libvector.a -o mytask
动态链接
同样，假设您使用的是 gcc，它看起来像这样：
g++ -c file1.cpp -fPIC -o file1.o
g++ -c file2.cpp -fPIC -o file2.o
...
g++ -c filen.cpp -fPIC -o filen.o
ld -G file1.o file2.o ... filen.o -o libvector.so
然后，当您构建自己的代码时，您的最终链接如下所示：
g++ myfile.cpp libvector.so -o mytask
您需要将 libvector.so 放在加载程序的路径中，以便您的可执行文件工作。
无论如何，只要 50,000 个文件没有变化，您只需执行最后一个命令（这会快得多）。
我们不能真正说出编译所需的时间，但你应该做的是将每个.cpp/.h对编译成一个.o文件：
$ g++ -c -o test.o test.cpp ...
一旦你有了所有这些，你就可以编译主程序：
$ g++ -c -o main.o main.cpp
$ g++ -o main main.o test.o blah.o otherThings.o foo.o bar.o baz.o etc...
您使用.sos 的想法几乎是在问“我可以多快使程序和操作系统崩溃？”。共享库适用于少量的大型库，而不是.so链接到二进制文件的 50,000 秒（特别是如果您动态加载它们……那将是糟糕的）。