在哪里/如何定义模板

Question

在 C++ 中定义模板的最佳实践是什么？

template <class T>
class A
{
private:
    // stuff
public:
    T DoMagic()
    {
        //method body
    }
}

Or:

template <class T>
class A
{
private:
    // stuff
public:
    T DoMagic();
}

template <class T>
A::T DoMagic()
{
    // magic
}

另一种方式？ 我似乎无意中发现了有关这个主题的一些争议。 所以;选择什么道路？

Answer 1

这完全是风格问题。不过，话虽如此：

1. 选择一种方式并坚持下去——要么全部内联，要么全部外联，或者根据某些规则进行混合，
2. 我个人使用 3 行规则。如果模板中的方法主体超过 3 行，我会将其移到外面。

没有真正的理由不包含所有内联定义（无论如何，它们都是从编译器 POV 内联的），但是，许多人认为将它们分开会更干净，并且允许类定义更具可读性。

Answer 2

随着您编写的模板变得越来越大、越来越复杂，请使用越来越高的分离级别。
无论如何将定义与声明分开，性能都是相同的，因此这里主要关注的应该是可读性和可维护性。

当编写仅在一个地方使用的简单模板时，请根据要使用它的 CPP 文件中的声明内联声明和定义它。如果只有一个代码块需要此模板，则没有理由强制进行全局重新编译。

file.cpp

template<class Gizmo> bool DoSomethingFancy()
{
 // ...
}

---

对于跨翻译单元使用的小型模板实用程序，请在 H 文件中一起定义和声明它们：

utility.h

template<class Gizmo> bool DoSomethingUseful() 
{
  // ...
}

---

随着模板变得越来越复杂，能够从定义中单独查看声明将变得更加重要。首先，将所有内容分开，但放在同一个文件中：

utility.h

template<class Type> class Useful
{
  bool FunctionA();
  bool FunctionB();
};

template<class Type> bool Useful<Type>::FunctionA()
{
  // ...
}

template<class Type> bool Useful<Type>::FunctionB()
{
  // ...
}

---

但最终，即使这样也会变得笨拙。当它出现时，将其分成一个用于声明的头文件和一个用于定义的 INC 文件。在头文件末尾，#include INC 文件：

utility.h :

template<class Type> class MoreUseful
    {
      bool FunctionA();
      bool FunctionB();
    };

#include "utility.inc"

utility.inc :

template<class Type> bool MoreUseful<Type>::FunctionA()
{
  // ...
}

template<class Type> bool MoreUseful<Type>::FunctionB()
{
  // ...
}

Answer 3

这是一个宗教（风格）问题。对于具有多个方法或少数方法很简单的类，我更喜欢在模板声明之外定义函数。

无论哪种情况，我的理解是模板声明和方法定义必须位于同一翻译单元中。这是因为模板更像是模板，编译器将给定类型插入模板并为给定类型生成代码。

无论你做出什么决定，只要保持一致即可。

Answer 4

我通常在外部定义所有方法，但每次我希望 C++ 有某种“模板块”：

template <class T>
struct A
{
     T foo();
     T bar(T * t);
     T baz(T const & t);
};

template <class T>  // Made-up syntax
{
    T A::foo()
    {
        //...
    }

    T A::bar(T * t)
    {
        //...        
    }

    T A::baz(T const & t)
    {
        //...
    }
}

Answer 5

如果函数很重要（即多于一行或两行），请考虑单独定义它们。这使得类的接口对于类的用户来说更容易导航、阅读和理解，他们很可能不必查看每个方法的实际实现。

Answer 6

对于像您的示例这样的一次性实例，这几乎没有什么区别。

当存在大量具有多种变化的模板时会发生什么？然后，它有助于将相似类型的苹果放在一起，并将相似类型的橙子放在远离它们的地方。当然，这一切都必须直观且实用地完成。这很大程度上受到程序员使用代码的文化的影响。