内联或不内联 [英] To inline or not to inline

问题描述

我最近写了几堂课;我想知道是不好的做法，不好的性能，打破封装，或者是否有任何其他固有的东西，实际上定义一些较小的成员函数内的头部（我没有尝试谷歌！这里有一个例子，我写了很多这样的头：

  class Scheduler {
 public ：
 typedef std :: list< BSubsystem *> SubsystemList; 
 
 //确保在init 
 //上指向entityManager的指针为零，这样我们可以检查是否在Tick（）中附加了一个
 Scheduler（）：entityManager 0）{} 
 
 //将管理器附加到调度程序 - 由Tick（）使用
 void AttachEntityManager（EntityManager& em）
 {entityManager =& } 
 
 //从调度程序分离entityManager。 
 void DetachEntityManager（）
 {entityManager = 0; } 
 
 //将一个子系统添加到调度器;在Tick（）上执行
 void AddSubsystem（BSubsystem * s）
 {subsystemList.push_back（s）; } 
 
 //删除给定类型的子系统
 void RemoveSubsystem（const SubsystemTypeID&）; 
 
 //执行所有子系统
 void Tick（）; 
 
 //销毁子系统列表中的子系统
 virtual〜Scheduler（）; 
 private：
 //保存所有子系统的列表
 SubsystemList subsystemList; 
 
 //保存实体管理器（如果已附加）
 EntityManager * entityManager; 
}; 
  

因此，有什么东西真的错误

（此外，我不确定这是否更适合'代码审查'网站）

解决方案

内联增加耦合，并增加类
定义中的噪声，使类更难阅读和理解。作为一个
的一般规则，内联应该被认为是一个优化措施，
，只有当profiler说有必要时才使用。

有一些例外：如果所有其他函数都是纯虚函数，我总是内联一个抽象基类的
的虚拟析构函数。
它似乎愚蠢有一个单独的源文件只是一个空的
析构函数，如果所有其他函数是纯虚拟，和
没有数据成员，析构函数不是要改变没有
的东西改变。我偶尔会为结构类提供内联的
构造函数，其中所有数据成员
都是公共的，并且没有其他函数。我也不太严格
关于避免在源文件中定义的类中的内联，
而不是标题;耦合问题显然不适用于
的情况。 p>

I've been writing a few classes lately; and I was wondering whether it's bad practice, bad for performance, breaks encapsulation or whether there's anything else inherently bad with actually defining some of the smaller member functions inside a header (I did try Google!). Here's an example I have of a header I've written with a lot of this:

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;
};

So, is there anything that's really wrong with inlining functions like this, or is it acceptable?

(Also, I'm not sure if this'd be more suited towards the 'code review' site)

解决方案

Inlining increases coupling, and increases "noise" in the class definition, making the class harder to read and understand. As a general rule, inlining should be considered as an optimization measure, and only used when the profiler says it's necessary.

There are a few exceptions: I'll always inline the virtual destructor of an abstract base class if all of the other functions are pure virtual; it seems silly to have a separate source file just for an empty destructor, and if all of the other functions are pure virtual, and there are no data members, the destructor isn't going to change without something else changing. And I'll occasionally provide inlined constructors for "structures"—classes in which all data members are public, and there are no other functions. I'm also less rigorous about avoiding inline in classes which are defined in a source file, rather than a header—the coupling issues obviously don't apply in that case.

这篇关于内联或不内联的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！