blocks|key|573590|text|应该始终将包含指令包括在需要它们的文件中，或者使读取和理解代码更容易。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|573591|在您的示例中，在控制台中包含了windows.h。对于这样一个常见的头文件，只将它放在控制台中是可以的。但是，如果您使用的是您编写的另一个库，并且还没有被广泛采用，那么明智的做法是将它包含在两个文件中，以防止未来的开发人员不得不通过头文件搜索提供控制台中提供的功能的头文件。|573592|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Include directives should always be included in the file that needs them, or to make reading and understanding your code easier. 

In your example, you include windows.h inside console.h. For such a common header file, it'd be fine to leave it in console.h only. However, if you were using another library that you'd written, and was not already widely adopted, it would be wise to include it in both files to prevent future developers from having to hunt through header files searching for the one which provided functionality seen in console.c.

blocks|key|121362|text|以下是一些原则：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|121363|不必要的包含头只会增加编译时间.
这听起来可能是可以忽略的，而且通常是这样的，但是如果你养成了太多包含的习惯，它就会成为一个问题。
假设您的项目有一个通用标题，其中包括所有其他项目头和它们可能需要的所有系统标头。因此，任何.c文件只需要包括这一个头，并完成它。这很方便。但是，除了稍微延长每个.c文件的编译时间之外，它还保证每次更改单个标头时都必须重新编译整个项目。这将大大减慢您的修改-编译-测试周期。|ordered-list-item|offset|length|style|BOLD|121364|您必须避免创建循环包含依赖项.
如果你确实创建了一个循环包含，你就有麻烦了。因此，最好避免包含任何不必要的内容:包含的越少，可以触发循环包含的标题就越少。有时，您可能需要插入前向声明而不是包含。|121365|+.c文件必须包括它的.h文件.
如果您做不到这一点，.c文件中的函数签名将不会根据.h文件中的声明进行检查，随后会出现疯狂。
这个原则的问题是，如果.c文件没有定义实现所需的类型，那么.h文件可以很好地编译，而无需包含。然而，包含必须在那里，以防止签名不匹配。|121366|因此，除了第3点之外，谨慎的做法是只包含绝对需要的头，并且只包含在实际需要它的文件中。就我个人而言，我经常只在收到编译器错误告诉我缺少了什么东西之后才包含一个标头。|121367|entityMap^0|0|0|G|0|0|F|0|0|G|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@$E|S|F|T|G|H]]|9|@]|A|$]]|$1|I|3|J|5|D|7|U|8|@$E|V|F|W|G|H]]|9|@]|A|$]]|$1|K|3|L|5|D|7|X|8|@$E|Y|F|Z|G|H]]|9|@]|A|$]]|$1|M|3|N|5|6|7|10|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|P|$]]

Here are some principles:

<ol>
<li>An unnecessarily included header only adds to the compilation time. 
This may sound ignorable, and it generally is, but if you get into the habit of including too much, it can become an issue.

Imagine you have a general header for your project, that includes all other project headers and all the system headers they may need. So any .c file only needs to include this one header and be done with it. This is convenient. However, apart from prolonging the compilation of each .c file a bit, it also guarantees that you have to recompile the entire project every time you change a single header. And that will significantly slow down your modify-compile-test cycle.</li>
<li>You must avoid creating circular include dependencies. 
If you do create a circular include, you are in for trouble. So, best avoid including anything unnecessary: the less you include, the less headers can trigger circular includes. Sometimes you may be required to insert a forward declaration instead of an include.</li>
<li>A .c file must include its .h file. 
If you fail to do this, the function signatures in the .c file won't be checked against the declarations in the .h file, and madness will follow.

The problem with this principle is, that your .c file may compile fine without the include if the .h file does not define a type that is needed by the implementation. Nevertheless, the include must be there to prevent signature mismatches.</li>
</ol>

So, apart from point 3, it is prudent to only include headers that are absolutely needed, and only in the file that actually needs it. Personally, I frequently only include a header after I get a compiler error telling me that something is missing.

blocks|key|122204|text|我只会对您的设置进行两次更改。我将在头文件中包含所有头部，但console.h头除外，这是包含头文件所必需的。其次，当您使用#define+CONSOLE_H++1时，给它一个值，1就可以了。我只是防止一个未初始化的标签。看起来不错。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|122205|console.h|122206|#ifndef+CONSOLE_H
#define+CONSOLE_H++1

#include+<windows.h>
#include+<stdlib.h>

void+gotoxy+(const+WORD+x,+const+WORD+y);

void+clearScreen();

#endif|code-block|syntax|javascript|122207|console.c|122208|#include+"console.h"

COORD+coord+=+{0,0};

void+gotoxy+(const+WORD+x,+const+WORD+y){
++++coord.X+=+x;
++++coord.Y+=+y;
++++SetConsoleCursorPosition(GetStdHandle(STD_OUTPUT_HANDLE),+coord);
}

void+clearScreen(){
++++system("cls");
}|122209|entityMap^0|U|9|1Q|K|2I|1|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|10|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|11|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|Q|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|R|$]]

There are only two changes to your setup I would make. I would include all headers in the header file except for the <code>console.h</code> header which is necessary to include the header. Second, when you <code>#define CONSOLE_H 1</code>, give it a value <code>1</code> is fine. I just prevents an uninitialized tag. Looks good.

console.h

<pre><code>#ifndef CONSOLE_H
#define CONSOLE_H 1

#include &lt;windows.h&gt;
#include &lt;stdlib.h&gt;

void gotoxy (const WORD x, const WORD y);

void clearScreen();

#endif
</code></pre>

console.c

<pre><code>#include "console.h"

COORD coord = {0,0};

void gotoxy (const WORD x, const WORD y){
 coord.X = x;
 coord.Y = y;
 SetConsoleCursorPosition(GetStdHandle(STD_OUTPUT_HANDLE), coord);
}

void clearScreen(){
 system("cls");
}
</code></pre>

blocks|key|122227|text|就像它已经在评论和其他答案中提到的那样--应该包含在需要它们的文件中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|122228|但是，对于复杂/大型项目，我建议设计接口，使它们只需要对实际数据的处理程序/引用，而不需要实际数据。这允许在头文件中使用前向声明，在实现文件中使用实际的包含。其原因是避免了紧耦合。紧密的耦合通常会导致非常有问题的行为，强迫包含不直接需要的头(甚至创建循环依赖关系，导致编译失败和需要进行广泛的更改！)，增加编译时间并损害诸如模块化、可维护性和可伸缩性等SW质量属性。|offset|length|style|BOLD|122229|也就是说，在大多数情况下(例如stdio.h、windows.h等)都需要一些常见的标头(通常是您正在使用的环境的一部分)--包括这些标题不会损害SW的质量，尽管编译时间可能还会增加。处理此问题的一种方法是使用预编译头。|122230|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Coupling_%2528computer_programming%2529|1|http://en.wikipedia.org/wiki/Precompiled_header^0|0|2E|3|2L|2|0|0|2X|4|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@$D|V|E|W|F|G]]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@$D|11|E|12|1|13]]|A|$]]|$1|J|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

Like it was already mentioned in comments and other answers - includes should be in the file that needs them. 

However, for complex/large projects, I'd recommend to design the interfaces such that they require only handlers/references to actual data instead of actual data. This allows usage of forward declarations in header files and actual includes in the implementation files. The reason for this is avoidance of tight coupling. Tight <a href="http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29" rel="nofollow">Coupling</a> often leads to very problematic behavior, forcing to include headers that aren't directly needed (and even creating circular dependencies, resulting in compilation failures and need for extensive changes!), increasing compilation time and harming such SW quality attributes as modularity, maintainability and scalability.

That said, there are common headers (usually part of the environment you're using) that are needed in most situations (e.g., stdio.h, windows.h etc.) - including these won't hurt the SW quality although the compilation time might still increase. One way to deal with this is to use <a href="http://en.wikipedia.org/wiki/Precompiled_header" rel="nofollow">Precompiled headers</a>.

In separating the interface from implementation in C, where is the right place to include a header file?

In the interface file (.h file) or in the implementation file (.c file)? Why?

My Sample Code:

console.h

<pre><code>#ifndef CONSOLE_H
#define CONSOLE_H

#include &lt;windows.h&gt;

void gotoxy (const WORD x, const WORD y);

void clearScreen();

#endif
</code></pre>

console.c

<pre><code>#include &lt;stdlib.h&gt;
#include "console.h"

COORD coord = {0,0};

void gotoxy (const WORD x, const WORD y){
 coord.X = x;
 coord.Y = y;
 SetConsoleCursorPosition(GetStdHandle(STD_OUTPUT_HANDLE), coord);
}

void clearScreen(){
 system("cls");
}
</code></pre>

Separating the Interface and Implementation in C

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在将接口与C中的实现分离时，包含头文件的正确位置在哪里？在接口文件(.h文件)中还是在实现文件(.c文件)中？为什么？我的样本代码：console.h#ifndef CONSOLE_H#define CONSOLE_H#include <windows.h>void gotoxy (const WORD x, cons...

问C语言中的接口分离与实现
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C语言中的接口分离与实现EN