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

Question

模板的可维护性是一个问题.当您在专用于通用库的社区外工作时,这是一个简单的事实.我不希望我的朋友和同事必须使用Clang来运行我的代码,只是因为......嗯...那么它不是真正的通用和便携,是吗？但我迫切希望能够偶尔编写一些模板化的代码.

您使用哪些技巧来使模板化代码更易于使用,更易于维护,并且更具可读性？像描述性模板参数,enable-ifs和代码风格的类似小怪癖,一直到关于哪些编译器支持可变参数模板或要避免哪些模板(反)模式的建议.

简而言之,我应该避免哪些成语？我应该依靠哪个？
我希望我的代码优雅但不太优雅.

我发现的一些资源:
C++ FAQ
Error Decrypt
什么是可变参数模板？

Answer 1

我使用以下方法:

• 在detail_命名空间中隔离您的众多类助手; 只揭露必要的东西.
• 对于(几乎)每个模板类,提供一个辅助函数来构造类型:它对迭代器和仿函数特别有用,然后可以内联构造.为此使用一个好的命名方案:iterator_transformer<Iter, F>由...构造transform_iterator.
• 使用一个好的命名方案(类的名词,方法的动词,枚举的形容词).采用后缀约定(_traits,, _concept...)并坚持下去(1)
• 有一个模板元编程的约定:对我来说type是返回类型的元函数的"返回类型",value是返回静态const整数的函数的静态const返回类型,other用于返回模板的元函数.你可能想要使用boost MPL,如果你滥用元编程,并遵循他们的约定(感谢@Noah Roberts)
• 不要吝啬:做最适合你需要的事情.只有在为代码带来某些东西时才使用泛型编程.有时,普通的多态性更好.
• 在标题中组织您的代码:内联实现进入您在"includable"标题中#include的"实现标题"文件
• 强迫自己使用标准算法:它们使代码更具可读性
• 提供玩具/测试/样本课程,特别是如果您希望人们扩展您的代码.
• 经常使用typedef:您应该像往常一样努力不对代码进行注释.
• 不要因为编译器早期失败而偏执:很少使用enable_if,这会使代码的可读性降低.但是你可以在内部使用它.
• 您有两个主要工具:函数模板的模板参数推导,以及类模板的部分特化的模式匹配.您应该尝试以最简单的方式使用这些工具.特别是,不要尝试根据类型是实现某个概念还是滥用来重载函数enable_if.把事情简单化.
• 将复杂类的实现拆分为更简单的类.在这方面滥用特质课程(感谢@Noah Roberts)

(1)我_concept用于CRTP模式的基类(即"静态多态").CRTP很好,因为它允许您使用最少的代码优化默认实现.

Answer 2

我同意这里的大多数答案，其中指出模板是（越来越多？）该语言的重要组成部分，并且没有人可以假装自己是 C++ 开发人员，但不能阅读一些合理的模板代码。

然而，模板可能会变得凌乱，所以我倾向于遵循一些准则：

• 只在details命名空间中显示严格的最小值并隐藏详细信息，或者更好的是，在单独的头文件中
• 如果可能，使用默认模板参数来简化语法：没有人喜欢一遍又一遍地编写完全相同的模板参数列表
• 请记住，有时，模板也可能是一个实现细节：它们作为给定问题的选择实现并不会阻止您向库用户公开单个抽象基类
• 使用typedef尽可能多的：当一个模板类的“家庭”携手共进，往往期望非常相同的模板参数，提供嵌套的typedef（在“主”库对象，或在一个单独的模板struct）。
• 注释您的代码，最值得注意的是表达对每个模板参数的要求