我个人使用c++的风格总是把类声明放在包含文件中,定义放在。cpp文件中,这很像Loki对c++头文件的回答,代码分离。不可否认,我喜欢这种风格的部分原因可能与我花了这么多年来编写Modula-2和Ada有关,这两者都有类似的规范文件和主体文件方案。

我有一个同事,他比我更了解c++,他坚持认为所有c++声明都应该尽可能地在头文件中包含定义。他并不是说这是一种有效的替代风格,甚至不是一种稍微更好的风格,而是说这是一种新的普遍接受的风格,现在每个人都在使用c++。

我不像以前那么灵活了,所以在我看到更多的人和他在一起之前,我并不急于加入他的行列。那么这个习语到底有多普遍呢?

只是给答案一些结构:现在的方式™,非常常见,有点常见,不常见,还是疯狂?


当前回答

我认为把所有的函数定义都放在头文件中是非常荒谬的。为什么?因为头文件被用作类的PUBLIC接口。这是“黑匣子”的外部。

当您需要查看一个类以引用如何使用它时,您应该查看头文件。头文件应该给出它能做什么的列表(注释以描述如何使用每个函数的细节),它应该包括一个成员变量列表。它不应该包括每个单独的函数是如何实现的,因为那是一船不必要的信息负载,只会使头文件混乱。

其他回答

正如图马斯所说,你的头球应该是最小的。为了完整,我将展开一点。

我个人在我的c++项目中使用4种类型的文件:

Public: Forwarding header: in case of templates etc, this file get the forwarding declarations that will appear in the header. Header: this file includes the forwarding header, if any, and declare everything that I wish to be public (and defines the classes...) Private: Private header: this file is a header reserved for implementation, it includes the header and declares the helper functions / structures (for Pimpl for example or predicates). Skip if unnecessary. Source file: it includes the private header (or header if no private header) and defines everything (non-template...)

此外,我还附带了另一条规则:不要定义可以转发声明的内容。当然,我在那里是合理的(到处使用皮impl是相当麻烦的)。

这意味着我更喜欢在头文件中使用前向声明,而不是使用#include指令。

最后,我还使用了一个可见性规则:我尽可能地限制符号的作用域,这样它们就不会污染外部作用域。

总的来说:

// example_fwd.hpp
// Here necessary to forward declare the template class,
// you don't want people to declare them in case you wish to add
// another template symbol (with a default) later on
class MyClass;
template <class T> class MyClassT;

// example.hpp
#include "project/example_fwd.hpp"

// Those can't really be skipped
#include <string>
#include <vector>

#include "project/pimpl.hpp"

// Those can be forward declared easily
#include "project/foo_fwd.hpp"

namespace project { class Bar; }

namespace project
{
  class MyClass
  {
  public:
    struct Color // Limiting scope of enum
    {
      enum type { Red, Orange, Green };
    };
    typedef Color::type Color_t;

  public:
    MyClass(); // because of pimpl, I need to define the constructor

  private:
    struct Impl;
    pimpl<Impl> mImpl; // I won't describe pimpl here :p
  };

  template <class T> class MyClassT: public MyClass {};
} // namespace project

// example_impl.hpp (not visible to clients)
#include "project/example.hpp"
#include "project/bar.hpp"

template <class T> void check(MyClass<T> const& c) { }

// example.cpp
#include "example_impl.hpp"

// MyClass definition

这里的救星是大多数时候forward头是无用的:只有在typedef或模板的情况下才需要,实现头也是;)

我把所有实现都放在类定义之外。我想把doxygen注释从类定义中删除。

模板代码应该只在头文件中。除此之外,除了内联之外的所有定义都应该在.cpp中。最好的参数是遵循相同规则的std库实现。你不会不同意std lib开发人员在这方面是正确的。

如果这个新方法真的是方法,我们可能在我们的项目中遇到了不同的方向。

因为我们尽量避免在头文件中出现不必要的东西。这包括避免头级联。头文件中的代码可能需要包含一些其他头文件,而这些头文件又需要另一个头文件,以此类推。如果我们被迫使用模板,我们尽量避免在标题中使用太多模板。

如果适用,我们还使用“不透明指针”模式。

通过这些实践,我们可以比大多数同行更快地构建。是的……更改代码或类成员不会导致巨大的重构。

这难道不是取决于系统的复杂性和内部约定吗?

目前,我正在研究一个非常复杂的神经网络模拟器,我期望使用的公认风格是:

classname.h中的类定义 classnameCode.h中的类代码 classname.cpp中的可执行代码

这将用户构建的模拟从开发人员构建的基类中分离出来,在这种情况下效果最好。

但是,如果有人在图形应用程序或其他目的不是为用户提供代码库的应用程序中这样做,我会感到惊讶。