模板编程的可维护性建议和最佳实践

Question

模板的可维护性是一个问题。这是一个简单的事实，当您在致力于泛型库的社区之外工作时。我不希望我的朋友和同事不得不使用Clang来运行我的代码，原因很简单……好吧..。那么它并不是真正的通用和可移植的，不是吗？但我确实非常希望能够时不时地写一些模板化的代码。

您使用了哪些技巧来使模板化代码更易用、更易维护、更具可读性？像描述性模板参数，enable-if，以及类似的代码风格的小怪癖，一直到关于编译器支持可变模板或避免什么模板(反)模式的建议。

简而言之，我应该避免哪些习惯用法？我应该依靠哪一个？

我希望我的代码是优雅的，但不是太优雅。

我找到了一些资源：

C++ FAQ

Error Decrypt

What are variadic templates?

Answer 1

我使用以下方法：

• 在detail_命名空间中隔离了大量的类帮助器；只公开必要的内容。
• 为(几乎)每个模板类提供一个帮助器函数来构造类型:它对迭代器和函数器特别有用，然后可以内联构造它们。为此使用一个好的命名方案：iterator_transformer<Iter, F>是由一个好的命名方案(名词表示类，动词表示方法，形容词表示枚举)构造的。采用后缀约定(_traits，_concept，...)(1)
• 对模板元编程有一个约定:对我来说，type是返回类型的元函数的“返回类型”，value是返回静态常量整数的函数的静态常量返回类型，other是返回模板的元函数的返回类型。如果你滥用元编程，你可能想使用boost Roberts)
• Don't，并遵循他们的约定(感谢@Noah MPL :做最简单的事情，满足你的需求。只有当泛型编程给你的代码带来一些东西时，才使用泛型编程。有时候，简单的多态性是在头文件中定义你的代码:内联实现进入你#包含在你的“可包含”头文件中的“better.
• Organize header”文件中，强制你自己使用标准算法:它们使代码更像readable
• Provide玩具/测试/样本类，特别是如果你想要人们扩展你的代码。
• 经常使用typedef:你应该像往常一样努力不注释你的代码。
• 不要偏执地让编译器过早地失败:很少使用enable_if，它会使代码更难读。你可以在内部使用它。
• 你有两个主要的工具:函数模板的模板参数推导，以及类模板的部分特殊化的模式匹配。您应该尝试以最简单的方式使用这些工具。特别是，不要试图根据类型是否实现某个概念来重载函数，也不要滥用enable_if。将复杂类的实现保持为更简单的simple.
• Split。这方面的滥用特征类(感谢@Noah Roberts)

(1)我使用_concept作为CRTP模式的基类(即，“静态多态性”)。CRTP很好，因为它允许您用最少的代码来改进默认实现。

Answer 2

我同意这里的大多数答案，这些答案表明模板是一个(越来越多?)这是该语言的重要组成部分，如果不能阅读一些合理的模板代码，任何人都不能假装是一名C++开发人员。

然而，模板可能会变得杂乱无章，所以我倾向于遵循一些指导原则：

• 只在details命名空间中显示严格的最小值和隐藏细节，或者更好的是，在一个单独的头文件中
• ，尽可能使用默认模板参数来简化语法:没有人喜欢一遍又一遍地编写完全相同的模板参数列表
• 记住，有时，模板也可能是实现细节:作为给定问题的首选实现，不会阻止您向库用户公开单个抽象基类
• 尽可能多地使用<代码>D9：当模板类的“家族”一起工作并倾向于期望非常相同的模板参数时，提供嵌套类型定义(在'main‘库对象中，或者在代码的单独模板中)，最明显的是表达每个模板参数

上的要求

Answer 3

我不太明白。模板的问题是由于很难获得正确的包含顺序和声明/定义顺序，而不是可移植性。

模板化代码的可移植性不亚于常规代码。