问题描述
那是正确的（甚至是推荐/好习惯），以的#include .C在另一个.c文件的文件？当它们被包含在项目文件中，会发生什么？
Is it OK (or even recommended/good practice) to #include .c file in another .c file? What happens when they are included in a project file?
推荐答案
使用得当，这可能是一个有用的技术。
Used properly, this can be a useful technique.
假设你有一个相当小的公共接口复杂，性能的关键子系统和大量的不可重复使用的执行code的。在code运行到几千线，百元左右的私人活动和相当多的私人数据。如果你有不平凡的嵌入式系统的工作，你可能处理这种情况经常不够。
Say you have a complex, performance critical subsystem with a fairly small public interface and a lot of non-reusable implementation code. The code runs to several thousand lines, a hundred or so private functions and quite a bit of private data. If you work with non-trivial embedded systems, you probably deal with this situation frequently enough.
您的解决方案可能会分层，模块化，解耦和这些方面可以有效地重新presented和编码在不同的文件子系统的不同部位加强。
Your solution will probably be layered, modular and decoupled and these aspects can be usefully represented and reinforced by coding different parts of the subsystem in different files.
使用C，你可以这样做失去了很多。几乎所有的工具链提供了一个单一的编译单元像样的优化，但对任何事情声明为extern非常悲观。
With C, you can lose a lot by doing this. Almost all toolchains provide decent optimisation for a single compilation unit, but are very pessimistic about anything declared extern.
如果你把一切都在一个C源程序模块，你得到 -
If you put everything into one C source module, you get -
-
性能和放大器; code尺寸的改进 - 函数调用在许多情况下被内联。即使没有内联，编译器有机会产生更有效的code。
Performance & code size improvements - function calls will be inlined in many cases. Even without inlining, the compiler has opportunities to produce more efficient code.
链路级数据＆安培;功能躲藏起来。
Link level data & function hiding.
命名空间的污染及其配套的避免 - 你可以用更少的笨拙的名字
Avoidance of namespace pollution and its corollary - you can use less unwieldy names.
更快的编译和放大器;联动。
Faster compilation & linkage.
但你也得到一个邪恶的混乱，当谈到编辑这个文件，你失去了暗示模块化。这可以通过把源成多个文件，并包括这些以产生单一的编译单元来克服。
But you also get an unholy mess when it comes to editing this file and you lose the implied modularity. This can be overcome by splitting the source into several files and including these to produce a single compilation unit.
您需要施加一些约定虽然正确地管理这一点。这将取决于你的工具链在一定程度上，但有些一般的指针 -
You need to impose some conventions to manage this properly though. These will depend on your toolchain to some extent, but some general pointers are -
-
把公共接口在一个单独的头文件 - 你应该反正做这个
Put the public interface in a separate header file - you should be doing this anyway.
有一个包括所有子公司.c文件一个主.c文件。这也可以包括code的公共接口。
Have one main .c file that includes all the subsidiary .c files. This could also include the code for the public interface.
使用编译器守卫，以确保私人头文件和源模块不包括外部编译单元。
Use compiler guards to ensure that private headers and source modules are not included by external compilation units.
所有的私人数据和放大器;函数应该声明为static。
All private data & functions should be declared static.
维护.c和.h文件的概念上的区别。这充分利用了现有的约定。所不同的是，你将有很多你的头的静态声明。
Maintain the conceptual distinction between .c and .h files. This leverages existing conventions. The difference is that you will have a lot of static declarations in your headers.
如果您的工具链不施加任何理由不，命名私有实现文件作为.C和.h。如果使用包括警卫，这些都会产生任何code和引进任何新的名字（你也可以联动期间有一些空段结束）。巨大的优势是其他工具（例如，集成开发环境）将相应地处理这些文件。
If your toolchain doesn't impose any reason not to, name the private implementation files as .c and .h. If you use include guards, these will produce no code and introduce no new names (you may end up with some empty segments during linkage). The huge advantage is that other tools (e.g. IDEs) will treat these files appropriately.
这篇关于包括另外一个C源文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！