内联或不内联

Seb*_*fel 10 c++ header function member inlining

我最近写了几堂课; 我想知道这是不好的做法,对性能有害,打破封装,还是在标题中实际定义一些较小的成员函数是否还有其他任何不妥之处(我确实试过谷歌!).这是一个我有一个标题的例子我写了很多这个:

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;
};
Run Code Online (Sandbox Code Playgroud)

那么,这样的函数内联是否存在任何问题,或者它是否可以接受?

(另外,我不确定这是否更适合'代码审查'网站)

Jam*_*nze 11

内联增加了耦合,并增加了类定义中的"噪声",使得类更难以阅读和理解.作为一般规则,内联应被视为优化措施,仅在分析器表明有必要时使用.

有一些例外:如果所有其他函数都是纯虚函数,我将始终内联抽象基类的虚析构函数; 为一个空的析构函数创建一个单独的源文件似乎很愚蠢,如果所有其他函数都是纯虚拟的,并且没有数据成员,那么析构函数不会在没有其他更改的情况下发生更改.我偶尔也会为"结构"提供内联构造函数 - 所有数据成员都是公共的,并且没有其他函数.对于在源文件中定义的类中避免内联而不是标题,我也不那么严格 - 在这种情况下,耦合问题显然不适用.

  • @thiton实施细节是试图了解班级提供的合同的人的噪音.并且按照`return m_someInternalValue;`的方式实现,绝对不会告诉读者返回的内容.您仍然需要注释来解释返回值的含义. (4认同)
  • 反对内联的另一个论点是,如果标题广泛#included,更改单个函数的实现可能会触发重建大部分项目.对于小型项目,这不是问题,但对于需要数小时编译的大型项目,这是一个很大的问题.另一方面,如果函数定义在常规源文件中,则在更改该函数时仅重新编译该源文件.它还可以减慢编译速度:每次包含标题时都必须重新编译内联函数,即使未使用内联函数也是如此. (3认同)
  • @Schnommus这对作者来说有点麻烦,但通常,当我开发一个类时,我会在编辑器的不同窗格中打开源代码和标题,因此在它们之间跳转很容易.(我可以从标题中复制/粘贴函数声明,删除尾随的`;`,然后从那里开始进行定义.)对于读者来说,我觉得找到实现很方便,我看看源文件,永远不会在标题中. (2认同)

csc*_*wan 6

你所有的会员职能都是单行的,所以在我看来这是可以接受的.请注意,内联函数实际上可能会减小代码大小(!!),因为优化编译器会增加(非内联)函数的大小,以使它们适合块.

为了使您的代码更具可读性,我建议使用内联定义,如下所示:

class Scheduler
{
    ...

    void Scheduler::DetachEntityManager();

    ...
};


inline void Scheduler::DetachEntityManager()
{
    entityManager = 0;
}
Run Code Online (Sandbox Code Playgroud)

在我看来,更具可读性.