现在快2022年了，c++为什么还要实现（.cpp）和声明（.h）分开？

像 Java 或 C# 都不需要声明头文件，C++ 委员会为什么不解决这个问题？

都有人贴stackoverflow的解答了，居然没人翻译，我来翻译一下，顺便夹点私货。

Why does C++ need a separate header file?stackoverflow.com/questions/1305947/why-does-c-need-a-separate-header-file

<翻译>

有些人认为的头文件的好处

• 头文件机制允许/强迫程序员分离实现和声明，单总体来说事实并非如此。头文件有大量的实现细节，比如非public接口的成员变量，比如函数直接在类定义中实现。实操层面这种分离完全没有实现。
• 头文件加速编译，因为每个单元可以独立编译。实际上C++是编译速度最慢的语言，而其中的一个原因就是叠床架屋的重复的头文件包含。反复的交叉的包含导致编译不同单元的时候头文件被反复解析。

实际上，头文件是来自70年代产生的C语言。那个年代的计算机内存小，不太可能把整个模块全部放在内存里。编译器处理文件就是从头读到尾，有了头文件编译器就可以这么做。（按，编译器可以把头文件当作文本替换直接拿进来用，但是又不用编译实现。）

C++为了向后兼容就用了这套系统。

放在今天，这个做法没有意义，既没有效率，又容易出错，还过分复杂。如果语言设计的目标是分离接口定义和实现，有的是别的办法。

C++0x本来就考虑过模块系统，想法和Java/C#类似，但是优先级不够就没做。（按，C++20的确有module系统了）。

</翻译>

以下私货

有人说可以分离定义和接口，我觉得头文件的确在某种程度上可以做的这点，实操中虽然不完美也就能用。有人说头文件可以用来在不分享源代码的情况下分享接口，也对。有人说这是为了和C的反向兼容，这的确是原因。

就题主的问题而言，为什么2022年了还要分开。答案很简单，因为是C++，C++就是祖宗之法不可变，祖传的C/C++怎么能说废就废，肯定得反向兼容。

就头文件的目的而言，上面说的接口和实现分离的确是可以用头文件来实现的。但要注意的是，对于没有包袱的语言来说，头文件并非实现这点的最佳解决方案。事实上包这种概念就比头文件好得多。

从实现上来说，Java/C#的二进制模块可以自带符号表和注释，那二进制模块本身就自带头文件信息了（实际上是从源代码编译出来抽象接口）。我既然可以用这样的包和类文件里抽象出一个定义，在IDE的支持下，它不比一个头文件香吗。我根本不用担心重复包含，循环引用之类的问题。和客户分享，我既可以分享自带定义信息的二进制模块，也可以选择只分享定义接口（但是最后客户总会需要你的二进制模块）。希望C++的模块也能早日普及。

说C++历来如此的，历来如此不表示这是对的。

说不喜欢头文件别用C++的，C++一大坨东西，有好有坏，头文件并非其中的精华。不好的改进了才好。

---

已经不用了。

C++20 有了模块，并且有一种名为“私有模块片段”（private module fragment, [module.private.frag]）的机制，它适用于一体化的写法。

私有模块片段这种机制使得一个翻译单元（同时它也是模块单元，并且需要是该模块中唯一的模块单元）中同时有导出和非导出的部分（正常来说分别用于接口和实现），从而就不需要接口和实现分成不同文件了。

示例：

export module my.unified.unit;
// 此处为接口部分
export int fun();

module : private;
// 此处为实现部分
int fun() { return 42; }

---

其它答主答的已经很好了，这里从另一些角度，让C/C++新手理解为什么这不是一个问题，反而是一个feature。

1、C/C++源码不只有.c、.cpp、.cc、.h，还可以是.inc、.abc、.txt等等任意后缀

什么？.inc是啥？

当然，你在任何一本C/C++教材中都不会看到这种用法。理解它的关键是要理解“预编译器”的运作原理，理解#define和#include的真正含义。

预编译器，本质上是一种单纯的文本替换工具。所以无论你#include什么东西，预编译器都会原样照搬，甚至你#include一张图片也不是不可能（？）。

预编译器只是忠实完成它的本职工作，一方面，你需要理解预编译的常规用法，比如避免头文件包含多次：

#ifndef __A_H__
#include "a.h"
#endif

另一方面，在深入使用C/C++时，你要意识到以上写法并非什么“本质标准”，并不是谁规定一定要这么写，它只是一种常用写法，而非本质。只要你对预编译理解够深入，还能玩出各种花样来。

使用.inc、.txt等后缀，是为了既要让#include包含inc文件的内容，又不让IDE自动处理它，是一种较常见的变通方案。

2、链接

现代人学习C/C++，大都是用IDE，新建工程，写好h，写好cpp，然后build all，搞定。

这个过程跳过了十分重要的一步——链接。

每个c或cpp文件，会被编译为一个“编译单元”，一般是.o文件。之后，还要把这一堆.o文件，加上库文件，链接成完整的、最终的执行文件。

在C/C++原始标准中，其实对链接的定义是十分开放的，不同的编译器、不同的操作系统应该如何链接各有不同的实现。这种灵活的标准带来两个结果：

1. 高手可以自定义链接过程，精确定义执行文件的结构，以满足破解、加密、加壳等各种高级需求。
2. 普通用户只会自动编译，对链接过程细节一窍不通。

链接的过程还是比较深奥的，这里不打算在一个短短的回答中讲清楚。有兴趣可以看一本书：《程序员的自我修养——链接、装载与库》

3、声明与定义

你可以不理解链接过程，但是有一个相关知识点有必要搞清楚——声明与定义。

extern int a;    // 外部变量声明
int g = 0;       // 全局变量定义，由于有初始化，定义较强
int g2;          // 全局变量定义，没有初始化

int func(int a); // 函数声明
int func(int aa)
{
    return 0;
}  // 这是函数定义

static int s_func(int a) { ……}    // 这叫静态函数定义（被限定于模块内，有点模块私有那意思）

声明和定义最大的区别是：声明可以重复多次，而定义只能有一个。这对我们设计.h文件提出了限制——头文件里最好只有声明，没有定义。

声明与定义的区别是C/C++很重要的一个特点。但是很多人对它一知半解，造成了重复定义、模块划分不合理、嵌套定义、链接时间过长等等问题。

总而言之

C/C++把问题搞得这么复杂，不是多此一举，反而是十分有必要的。

当然未来C++的改进中，会加入更现代化的包管理方式，改进原始的链接方式。但是C语言应该不会接受这么剧烈的变化。

当你了解足够多的时候，你会发现C/C++提供了非常底层的控制方法，没有做不到，只有想不到。当然这给我们日常开发带来一些复杂度，但另一方面，也给技术进步留下了尽可能大的探索空间。