在C++类对应的cpp文件之外实现类函数是否合理？

简单来说：这通常既不符合C++的工程规范，在很多场景下甚至会引发编译/链接问题，绝对不是推荐的做法。结合你给出的代码例子，我们来具体分析：

先看你代码里的问题 #

你在main.cpp里定义了Class1::privFunc()，这会带来几个明显问题：

• 链接错误风险：编译class1.cpp时，编译器看到pubFunc()调用了privFunc()，会默认这个函数的定义在其他编译单元；但main.cpp里的privFunc()虽然是合法的成员函数定义，一旦项目规模扩大，其他依赖Class1的编译单元都会面临找不到privFunc()符号的问题（总不能每个用到Class1的.cpp都重复定义一遍，这显然是荒谬的）。
• 破坏封装性：Class1的私有成员函数属于类的核心实现细节，本该被封装在class1.cpp这个专属实现文件里。把它放在main.cpp里，等于把类的内部逻辑暴露给了完全无关的代码模块，直接违反了C++的封装原则——类的使用者（比如main.cpp的编写者）根本不需要知道privFunc()的存在，更不应该负责它的实现。

为什么要把类的实现放在对应.cpp文件里？ #

这是C++工程领域的标准实践，核心原因有三个：

• 封装与接口隔离：类的头文件（.h）只对外暴露公共接口，所有实现细节（包括私有函数、成员变量的具体操作逻辑）都放在.cpp中。这样修改实现时，不会影响所有包含头文件的编译单元，只需要重新编译对应的.cpp即可。
• 编译效率优化：如果类的实现分散在多个.cpp文件，任何一处实现的修改都会导致多个文件重新编译；集中在一个.cpp里，编译成本会大幅降低。
• 代码可维护性：所有和Class1相关的实现逻辑都集中在一个文件里，后续维护者可以快速定位所有相关代码，避免在多个文件间来回跳转、浪费时间。

有没有例外情况？ #

当然，也存在一些特殊场景会打破这个规则：

• 模板类/模板函数：由于模板的实例化机制，通常需要把实现放在头文件里（或者专门的.tpp文件并包含到头文件中）。
• inline函数：如果成员函数被声明为inline，为了让编译器能够正确进行内联优化，通常会把实现放在头文件里。

但这些都是特殊情况，对于你代码里的普通非模板类，绝对应该把所有成员函数的实现放在对应的.cpp文件里——比如把privFunc()的实现移到class1.cpp里，就像你已经做的构造函数和pubFunc()那样。

内容的提问来源于stack exchange，提问作者LaPXL8R