与C#和Java相比,编译C++文件需要很长时间.编译C++文件所需的时间比运行普通大小的Python脚本要长得多.我目前正在使用VC++,但它与任何编译器都是一样的.为什么是这样？
我能想到的两个原因是加载头文件和运行预处理器,但这似乎不应该解释为什么它需要这么长时间.
我来自脚本背景,C中的预处理器对我来说总是很难看.然而,当我学习编写小型C程序时,我已经接受了它.我只是真的使用预处理器来包含我为自己的函数编写的标准库和头文件.
我的问题是为什么C程序员不会跳过所有包含并简单地连接他们的C源文件然后编译它？如果将所有包含放在一个位置,则只需要定义一次所需内容,而不是在所有源文件中定义.
这是我所描述的一个例子.这里我有三个文件:
// includes.c
#include <stdio.h>
// main.c
int main() {
foo();
printf("world\n");
return 0;
}
// foo.c
void foo() {
printf("Hello ");
}
通过cat *.c > to_compile.c && gcc -o myprogram to_compile.c在我的Makefile中执行某些操作,我可以减少我编写的代码量.
这意味着我不必为我创建的每个函数编写头文件(因为它们已经在主源文件中),这也意味着我不必在我创建的每个文件中包含标准库.这对我来说似乎是一个好主意!
但是我意识到C是一种非常成熟的编程语言,我想象的是比我聪明的其他人已经有了这个想法,并决定不使用它.为什么不？
你如何减少VC++项目(原生C++)的编译时间和链接时间？
请指定每个建议是否适用于调试,发布或两者.
从一家新公司开始,我注意到他们在我们的大部分解决方案中使用了统一cpp文件,我想知道是否有人能够给出一个明确的理由,说明为什么以及如何加快构建过程？我原以为在Unity文件中编辑一个cpp文件会强制重新编译所有这些文件.
在某些情况下,我们包含.cpp文件而不是标准头文件(.h),例如:
#include "example.cpp"
代替
#include "example.h"
它似乎有用,但是这样安全还是我应该避免它？
编译时间怎么样？
我想减少大型C++项目的编译时间.我尝试使用预编译的头文件,接口等.但在我继续之前,我想知道是否有任何工具可以帮助检测为什么编译时间如此之长.有人建议使用pc-lint,我会试一试. 如何在大型C++项目中检测不必要的#include文件？ 但是,如果有其他工具可以分析编译时间并讨论任何提高编译速度的提示,请告诉我.提前致谢.
环境:Microsoft Visual Studio C++ 2008或2010.
我有一个包含多个源文件和多个头文件的c ++项目.我想提交我的项目进行编程竞赛,这需要一个源文件.是否有自动将所有文件折叠为单个.cpp文件的方法？
例如,如果我有a.cpp,ah,b.cpp,bh等,我想得到一个将成功编译和运行的main.cpp.如果我手动执行此操作,是否可以简单地合并头文件并将源文件相互附加？是否有外部问题,包括依赖和前向声明？
有人可以给我提高视觉工作室2008的建筑速度吗？
我有一个大型项目,包含许多具有完整源代码的模块.每次构建时,每个文件都会被重建,其中一些文件没有被更改.我可以阻止重建这些文件吗？我打开属性"启用最小重建"/ Gm,但编译器抛出此警告
Command line warning D9030 : '/Gm' is incompatible with multiprocessing; ignoring /MP switch
提高建筑速度的每一个提示都会对我有所帮助.谢谢,
我正在使用Visual Studio,似乎摆脱未使用的引用和使用语句可以加快我在大型项目上的构建时间.是否有其他已知的加速构建时间的方法.其他语言和构建环境怎么样？
什么是构建/编译期间的瓶颈？磁盘,CPU,内存？
什么是分布式构建的良好参考列表？
我们的下一个产品已经变得太大,无法在运行32位Windows的计算机上进行链接.所有lib文件的总和超过2Gb,只能在64位Windows机器上链接.最终我们将超越这个边界,因为我们的软件往往增长而不是契约,我们使用的是32位链接器(MS Visual Studio 2005):当我们的lib总大小超过3Gb时,我们预计会遇到麻烦.
如何在不修剪代码的情况下减小.lib文件或.obj文件的大小？例如,我们使用了很多模板:有没有办法减少它们的占用空间？有没有办法找出导致膨胀检查.lib/.obj文件的原因？这可以自动化而不是通过眼睛检查吗？2.5Gb是很多文本要比较和比较.
外部约束阻止我们作为单个.exe之外的任何东西进行传输,因此DLL解决方案不可用.