模板的可维护性是个问题。当您在专用于通用库的社区外工作时,这是一个简单的事实。我不希望我的朋友和同事必须使用Clang来运行我的代码,只是因为......嗯...那么它不是真正的通用和便携,是吗?但我迫切希望能够偶尔编写一些模板化的代码。
您使用哪些技巧来使模板化代码更易于使用,更易于维护,并且更具可读性?像描述性模板参数,enable-ifs和代码风格的类似小问题,一直到关于哪些编译器支持可变参数模板或要避免哪些模板(反)模式的建议。
简而言之,我应该避免哪些成语?我应该依靠哪一个? 我希望我的代码优雅但不太优雅。
我找到的一些资源:
C++ FAQ
Error Decrypt
What are variadic templates?
答案 0 :(得分:10)
我使用以下方法:
detail_
命名空间中隔离您的众多类助手;只披露必要的东西。iterator_transformer<Iter, F>
由transform_iterator
构建。_traits
,_concept
,...)并坚持下去(1)type
是返回类型的元函数的“返回类型”,value
是返回静态const整数的函数的静态const返回类型, other
用于返回模板的元函数。你可能想要使用boost MPL,如果你滥用元编程,并遵循他们的约定(感谢@Noah Roberts)enable_if
,这会使代码的可读性降低。但是你可以在内部使用它。enable_if
来重载函数。保持简单。(1)我使用_concept
作为CRTP模式的基类(即“静态多态”)。 CRTP很好,因为它允许您使用最少的代码优化默认实现。
答案 1 :(得分:4)
我同意这里的大多数答案,其中指出模板是该语言的一个(越来越多)重要的组成部分,并且没有人能够假装成为没有能力阅读合理模板代码的C ++开发人员。
但是,模板可能变得混乱,所以我倾向于遵循一些指导原则:
details
命名空间中显示严格的最小值并隐藏详细信息,或者更好地隐藏在单独的头文件中typedef
:当模板类的“族”一起工作并且倾向于期望相同的模板参数时,提供嵌套的typedef(在'main'库对象中,或者在单独的模板struct
)。答案 2 :(得分:1)
我真的不明白。模板的问题是由于难以使包含订单和声明/定义订单正确,而不是可移植性。
模板化代码的可移植性不低于常规代码。
答案 3 :(得分:-1)
在我看来,真正的问题是你正试图让非C ++程序员可以访问C ++代码。模板是C ++语言的重要组成部分,并且早在语言标准化之前就已存在。
如果你的同事遇到麻烦,那么很难说他们称他们为C ++程序员。那你真的只有两个选择:
答案 4 :(得分:-2)
自从我使用c ++以来,它已经过了很长一段时间,但随着你的进展,我会说可读性评论。因为在那个阶段我们遇到了麻烦,以后当你弄清楚它时没有用。其他人可能不会在那个层面理解它。此外,对于C ++中的模板,您可以使用虚函数,即具有通用属性和方法的员工的通用帐户,并在派生类中实现它们,例如兼职人员,经理等。
最重要的是,我建议你对编码标准感到满意,并在整个代码中保持统一,并使用空格。
这就是我能想到的一切。祝你好运