小编Toa*_*oul的帖子

我们有一个大型Visual Studio 2005 C++/Mfc解决方案,1个项目包含大约1300个源文件(大约650 .h和650 .cpp文件).我们还使用Boost和其他一些库(COM:MSXML,Office).

最近,我添加了一些boost :: multi_index实例来加速一些事情.这一切都在大部分时间汇编.但是现在,当我正在进行完整(发布)重建时,我会在几个模块上遇到编译器崩溃.

Fatal Error C1060: "compiler is out of heap space"

我已经尝试在预编译的头文件中减少包含(删除了除标准MFC头之外的所有内容).另外,我删除了编译器选项/ Zm200(我们在编译预编译头文件之前需要它).

奇怪的是:当我在编译器崩溃后按F7(build)时,构建过程继续没有任何问题(或者至少到下一次编译器崩溃,再次按F7).但是能够在没有任何中断的情况下完成构建将会很棒.

我可以影响各个模块的构建顺序吗？这样,我可以将"有问题"的模块放在流程的开头(并希望崩溃不只是转移到其他模块).

BTW:完整的构建大约需要90分钟.

更新:

谢谢你的回答.我能够摆脱编译器崩溃并显着减少编译时间.这是我做的:

1. 我从预编译的头文件中删除了所有包含,只是保留了标准的windows/mfc头文件.这迫使我将更多包含添加到其他模块中,但最终所有内容都包含在需要的地方.当然,这一步增加了编译时间,但让我在下一步更有效率.
2. 我安装了ProFactors IncludeManager的试用版.项目详细信息视图可以导出到Excel,可以非常快速地发现预编译头文件中包含的瓶颈和候选项.
3. 大多数编译时间浪费了一些头文件,其中包含一堆其他头文件(包括更多......).我不得不使用前向声明来摆脱一些讨厌的依赖.另外,我将一些类/函数从关键标题中移到了自己的模块中.
4. 在预编译头中放什么？(MSVC)帮助我在预编译头文件中获取包含权限.我添加了STL,Boost,Windows标题.然后添加我们自己的(或多或少稳定的,优化的)标头,以及资源头文件.
5. 我重复了第3步和第4步,总是用IncludeManager检查新候选人.
6. 步骤1到5使编译时间(释放模式)下降,从90到大约45分钟.
7. 我禁用了所有浏览信息的生成,因为我们似乎没有使用它(我找不到任何有关它真正有用的信息......).这又打破了构建过程的6分钟.
8. 我将/ MP(多处理器支持)开关添加到C++编译器命令.现在重建时间缩短到22分钟.这一切都是在一台核心PC上完成的.
9. 我将整个解决方案转移到双核PC上.重建项目需要16分钟.
10. 创建调试版本会快5分钟:
    • 单核机器上17分钟,
    • 双核机器上11分钟.

更新2:

上面,我提到"单核机器",实际上是一个较慢的双核机器.

有没有一种简单的方法可以在Windows下使用Visual Studio 2005 构建GMP(GNU多精度算术库,http://gmplib.org)？我试图找到有关自己构建库的信息,但找不到任何真正帮助我的东西.我自己建立图书馆的经验不是很丰富(我已经设法建立了提升,但就是这样).

还是有一个我不知道的稳定(预建)GMP发行版？

MPIR是一个有效的替代方案(http://www.mpir.org)吗？关于GMP网站上的MPIR的评论:对于一些Windows用户来说,这个"愤怒的GMP分叉"可能是真正的GMP的替代品,但他们必须处理大量的反GMP情绪.

编辑: MPFR C++包装页面包含指向Visual Studio的GMP/MPFR解决方案的信息/链接以及编译的gmp/mpfr库:http: //www.holoborodko.com/pavel/mpfr/

在我的WPF窗口中,我已经设置好了

Width="300" MinWidth="300" MaxWidth="300"

当我最大化这个窗口时,它会停靠在左边的屏幕边框上,但是窗口的底部部分是Windows 8任务栏的UNDERNEATH.

我试过了

public MainWindow()
{
    ...
    this.MaxHeight = System.Windows.SystemParameters.WorkArea.Height;
}

,但这导致任务栏和我的应用程序之间有一些像素的可用空间.

我想

• 有一个固定宽度的窗口
• 最大限度地将它停靠在右边框上
• 没有覆盖/进入最大化状态下的任务栏