将所有内容放在头文件中是否有任何*真正的*问题？

Question

我正在为嵌入式 (AVR) 开发，我的项目看起来像这样：

库/ - foobar.h -utils.h 主程序 生成文件

编译它很容易，基本上是ave-gcc main.c 加上一些额外的标志。

但是，如果我想添加更大的内容并将文件拆分为 h 和 c：

库/ - big_file.h // 原型 - big_file.c // 实现 - foobar.h -utils.h 主程序 生成文件

然后我必须在gcc 命令中包含这个.c 文件。

我发现如果我只是将所有内容放在标题中，这个问题就消失了。我真的不想每次做这样的事情时都编辑我的 Makefile。

这会导致任何真正的问题吗？

我不关心“最佳实践”，如果它意味着更容易使用。

Answer 1

我能想到的一些问题：

1. 您将不必要地暴露大量数据 - 当包含此头文件的文件中的声明不同时，这可能会导致错误

2. 头文件只应充当接口，以便明天您可以更改实现并继续使用相同的文件作为头文件。

这个程序员链接有很多我认为对你有帮助的讨论：https://softwareengineering.stackexchange.com/questions/167723/what-should-and-what-shouldnt-be-in-a-header-file。

Answer 2

脑海中浮现的一些。

• 您将失去翻译单元范围的好处 - 不在函数中的所有内容都将是全局的。
• 包含顺序至关重要，循环依赖将难以解决。
• 您无法从增量构建中受益 - 每次都会构建所有内容。
• 你的同事会恨你，认为你是个白痴。

这种做法可能适用于非常小的项目和琐碎的示例，但不适用于大型项目或团队开发的项目。对于更大、更复杂的项目，这些问题变得很明显。

我不关心“最佳实践”，如果它意味着更容易使用。

你应该关心； 最佳实践之所以如此，正是因为它们解决或预防了真正的问题。

如果您想要“更易于使用”，那么这远非最佳或最简单的解决方案。更好的解决方案是使用带有项目经理的 IDE。这将具有生成全面且准确的依赖项的额外好处，这在手动生成的 makefile 中难以维护，因此无论如何最好使用 IDE 或至少使用 makefile 生成器。

Answer 3

1. 所有包含该文件的人都可以看到您的所有数据和代码。
2. 应用程序的可移植性降低，因为标头有很多控制流代码[如果有任何特定于平台的代码]，那么使用它的所有文件都可能受到影响。稍后需要进行更多测试和验证。
3. headers 的一般做法是避免在此处添加控制，而只是在界面和定义方面添加敏感。