c++ - 在 C++ 中将包含方法定义的类声明放在头文件中是否被认为是错误的形式？

Question

我习惯了 C，其中头文件通常只包含声明而不包含定义，但 C++ 似乎鼓励两者混合，至少在类中是这样。采用可以轻松放入头文件中的此类声明。它的一些方法是内联定义的，不是在“内联”关键字的意义上，而是在类声明本身内内联。特别是构造函数和四个 getter/setter。

MyClass.h:

    class MyClass {
        public:
            MyClass(int a = 0, int b = 1) : _a(a), _b(b)  {};
            int getA() { return _a; };
            int getB() { return _b; };
            void setA(int a) { _a = a; };
            void setB(int b) { _b = b; };
            void doSomething(); // no definition here; defined in source file
            void doSomething2(); // no definition here; defined in source file
            void doSomething3(); // no definition here; defined in source file
        private:
            int _a;
            int _b;
    };

这种形式不好吗？我应该在源文件中单独定义类的方法，只在类声明中保留方法声明，还是完全可以接受？

Answer 1

它可能是错误的形式，这取决于使用标题的应用程序的“大局”。通过将实现放入 header 中，您需要在该实现更改时修改 header ......此类修改触发/需要使用许多构建系统(例如 make)重新编译客户端对象。相比之下，线外更改可能需要重新链接，并且当使用共享库时，可以替换这些库，而无需对客户端应用程序进行任何更改。因此，当没有特别的理由使用内联时，许多应用程序共享的低级 header 往往更喜欢外联实现。当预计实现需要更改时尤其如此。

有些人喜欢分离实现的另一个原因是避免混淆将 API 作为文档形式阅读的人。当阅读的内容较少时，它通常会更清晰，尽管有时实现有助于理解功能。但是，看到实现的程序员倾向于考虑行为/性能影响并构建依赖于此的客户端代码，即使接口(interface)没有做出严格保证:如果实现发生变化，这会使客户端代码变得脆弱。