将所有美学考虑放在一边......哪种替代方案更受欢迎？我主要关心的是构建时间，保持代码可读性和易于保持，当然还有编译。
我已经看到大多数书籍都在.cpp文件中定义了所有内容，而不是＃C＃，但是......是否会使构建时间恶化？好的，很可能是非托管C ++原理并不适用于托管C ++ / CLI，但请考虑转换场景：非托管C ++的项目类被移动进入一个C ++ / CLI项目，整个怪物构建正常，并坐在那里等待一个勇敢的家伙（我，咳咳）将非托管类转换为托管类，当然，逐步并使用支持测试工具。
我离题了一点，但我想让你在回答时考虑我的异常情况（管理和非托管互动）。
答案 0 :(得分：5)
.h文件是预处理器的工件。当编译器开始编译代码时，它只是一大堆代码。在C ++ / CLI中，.h文件的使用大大减少，您不再需要它来为其他模块提供声明。在托管代码中，程序集中的元数据提供它们。
C ++ / CLI保留了C ++的构建模型，它一次编译一个源代码文件，需要链接器将代码粘合在一起。如果您的一个项目的C ++ / CLI代码分布在多个源代码文件中，您可能仍需要.h文件。
因此，只有在需要时才使用.h文件。对本地项目没有什么不同的建议。