内联或不内联

Question

我最近写了几个类；我想知道它是否是糟糕的实践、性能不好、封装中断，或者实际上在头文件中定义了一些较小的成员函数(我尝试过了！)。下面是我用过的很多内容编写的标题的一个例子：

class Scheduler {
public:
    typedef std::list<BSubsystem*> SubsystemList;

    // Make sure the pointer to entityManager is zero on init
    // so that we can check if one has been attached in Tick()
    Scheduler() : entityManager(0) { }

    // Attaches a manager to the scheduler - used by Tick()
    void AttachEntityManager( EntityManager &em )
        { entityManager = &em; }

    // Detaches the entityManager from a scheduler.
    void DetachEntityManager()
        { entityManager = 0; }

    // Adds a subsystem to the scheduler; executed on Tick()
    void AddSubsystem( BSubsystem* s )
        { subsystemList.push_back(s); }

    // Removes the subsystem of a type given
    void RemoveSubsystem( const SubsystemTypeID& );

    // Executes all subsystems
    void Tick();

    // Destroys subsystems that are in subsystemList
    virtual ~Scheduler();
private:
    // Holds a list of all subsystems
    SubsystemList subsystemList;

    // Holds the entity manager (if attached)
    EntityManager *entityManager;
};

那么，这样的内联函数是否真的存在错误的，还是可以接受呢？

(而且，我也不确定这是否更适合于“代码评审”站点)

Answer 1

内联增加了类定义中的耦合，增加了“噪音”，使类更难阅读和理解。通常情况下，内联应该被看作是一种优化措施，并且只有当分析器认为它是必要的时候才使用。

有几个例外:如果所有其他函数都是纯虚拟的，那么我将总是内联抽象基类的虚拟析构函数；只为一个空析构函数拥有一个单独的源文件似乎很愚蠢，而且如果所有其他函数都是纯虚拟的，并且没有数据成员，那么析构函数将不会在没有其他更改的情况下进行更改。我偶尔会为“structures”-classes提供内联的构造函数，其中所有的数据成员都是公共的，并且没有其他函数。对于避免在源文件中定义的类(而不是头)中避免内联，我也没有那么严格--耦合问题显然不适用于这种情况。

Answer 2

您的所有成员函数都是一行函数，因此在我看来，这是可以接受的。注意，内联函数实际上可能会减少的代码大小(!!)因为优化编译器增加了(非内联)函数的大小，以便使它们适合块。

为了提高代码的可读性，我建议使用行内定义如下：

class Scheduler
{
    ...

    void Scheduler::DetachEntityManager();

    ...
};


inline void Scheduler::DetachEntityManager()
{
    entityManager = 0;
}

在我看来，这更容易读懂。

Answer 3

我认为内联(如果我理解正确的话，您指的是将琐碎代码直接写入头文件的习惯，而不是编译器行为)有助于可读性的因素有两个：

1. 将琐碎的方法和非平凡的方法区分开来，
2. 使琐碎方法的效果一目了然，这是自记录代码.

。

从设计POV来看，这并不重要。在不更改subsystemList成员的情况下，您不会更改内联方法，在这两种情况下都需要重新编译。内联不会影响封装，因为方法仍然是一个具有公共接口的方法。

因此，如果该方法是一个愚蠢的一行程序，不需要冗长的文档，或者可以想象的不包含接口更改的更改，那么我建议您使用内联方式。