Question

在我们等待（希望）传入的concepts时，库实现者定义宏是一个好主意吗？这种方法有哪些优点和缺点？

宏的例子（由A. Stepanov提供）：

#define TotallyOrdered typename
#define Pointer typename
#define Number typename
#define Unsigned typename
#define Integral typename
#define InputIterator typename
#define OutputIterator typename
#define ForwardIterator typename
#define BidirectionalIterator typename
#define RandomAccessIterator typename
...

示例用法（来自我）：

template<ForwardIterator It>
It min_element(It first, It last) { ... }

这个想法：

虽然没有概念，但它是一个普通的旧模板代码
当概念最终到达时，如果概念名称不同（您可以在任何体面的IDE中轻松完成），然后删除或只是将这些宏重新实现为概念表达式，您可以删除所有宏或重命名它们
利用未来功能而无需重写复杂的模板化代码
即使是现在，“键入”模板参数也可以更好地理解代码并释放开发静态概念检查工具的可能性

<子> 长篇故事： 亚马逊A9上有几个series of courses到A. Stepanov，他使用those macro替换typename关键字替换课堂中实施的算法的模板参数列表。由这个“面向指针的程序员”和所有C ++库的老大师迷住，我开始在任何地方使用这些宏。最近我被指出macro are ugly (and, also, that iterators are kinda obsolete, but this is another story)。所以现在我正在寻找其他专家对这种方法的建议。

<子> 有问题的库的例子：标准库的GPU加速版本（具有高度计算的东西，如数组结构，压缩迭代器等），线性代数库，树状数据结构，新算法函数

Answer 1

一个巨大的缺点是您的代码将撒谎。

我更喜欢

代码根本不使用概念，但如果/当它们存在，你可以改变它以便将来使用它们。

我不喜欢

代码根本不使用概念，但看起来像。无法想象比这更危险的事情。多大的虚假安全感会给维护者带来什么感受！

无论如何，你的想法都行不通。当概念出现时，您将不可避免地发现您在某个地方犯了一些错误，这些错误可能不会被您的旧编译器诊断出来。 您仍然需要更改代码。

现在，只需记录您的类型的前提条件/约束，就像您一直所做的那样。

Answer 2

正如其他人所说，这听起来不是一个好主意。标准通常使用模板参数的名称来描述其预期具有的属性。因此，例如，算法all_of被描述为

template <class InputIterator, class Predicate>
bool all_of(InputIterator first, InputIterator last, Predicate pred);

Answer 3

你可能只想拥有一个宏，比如CONCEPTS，并在这样的代码中使用它：

#ifdef CONCEPTS
// you concept based code
#else
// your temp workaround code
#endif

通过这种方式，您可以使用构建工具（例如 makefile）来控制是否使用概念。

#define作为缺少概念的解决方法

3 个答案: