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

Question

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

lib/
  - foobar.h
  - utils.h
main.c
Makefile

编译很容易，基本上ave-gcc main.c有一些额外的标记。

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

lib/
  - big_file.h // prototypes
  - big_file.c // implementation
  - foobar.h
  - utils.h
main.c
Makefile

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

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

这会导致真正的问题吗？

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

Answer 1

我能想到的一些问题：

1. 您将不必暴露大量数据 - 如果此声明在包含此头文件的文件中有所不同，这可能会导致错误

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

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

Answer 2

一些想到的东西。

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

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

  

我不关心＆＃34;最佳做法＆＃34;，如果这意味着更容易使用。

你应该关心; 最佳做法已成为现实，正是因为它们解决或阻止了真正的问题。

如果您希望＆＃34;更容易使用＆＃34;，那么这远非最好或最简单的解决方案。更好的解决方案是将IDE与项目经理一起使用。这将产生额外的好处，即生成全面而准确的依赖项，这很难在手动生成的makefile中维护，因此在任何情况下最好使用IDE或至少使用makefile生成器。

Answer 3

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