标准库实现专门化一个基于子概念的概念模板的函数合法吗

Is it legal for a standard library implementation to specialize a function templated on a concept with a child concept?

本文关键字：函数 专门化 实现 一个 标准      更新时间：2023-10-16

使用c++11和c++14库概念，c++标准库的有效实现是否可以创建一个以概念为模板的函数的专用版本，以利用子概念的附加功能进行优化，而这些优化仅使用基本概念是不可能的，例如使用std::vector的InputIterator构造函数，以及满足CCD_ 3要求的迭代器？

// specified by standard
vector(InputIt begin, InputIt end, const Allocator& alloc = Allocator());
// is this specialization allowed in an implementation if it provides the same functionality?
vector(RandomAccessIt begin, RandomAccessIt end, const Allocator& alloc = Allocator());

这里，InputIt是满足InputIterator概念要求的类型，而RandomAccessIt满足RandomAccessIterator的要求。值得注意的是，这个概念不需要查找两个迭代器之间的差异，而它的曾孙概念RandomAccessIterator确实需要

It a,b;
It::difference_type c = a - b;

有效。在RandomAccessIterator也是由所提供的迭代器实现的概念的情况下，找到两个迭代器之间的差异将有助于std::vector的InputIterator构造函数，因为这将允许实现预先分配最终向量所需的空间，而不是在构建过程中多次调整其大小。

我认为它是有效的，因为Standard偶尔会使用类似规则，比如在继承层次结构中使用虚拟函数的协变返回类型。然而，这些情况之间存在明显的差异，因此我也可以看到协变返回类型背后的逻辑可能不一定转移到这种情况。

重申一下：c++标准库的有效实现是否可以创建一个以概念为模板的函数的专用版本，以利用子概念的附加功能进行优化，而仅凭基本概念是不可能的？

注意：我没有用c++概念标记这个问题，因为据我所知，这个标记是针对concepts Lite和concepts TS的，这个问题是关于c++11和c++14中的库概念的

没有办法从外部确定用C++中的给定签名调用了哪个构造函数。

因此，vector签名的确切细节可以在假设规则下变化，只要指定的所有构造函数都可以调用，你得到的行为满足文档中的特性，并且任何无效的构造函数参数都保持无效（因为外部代码可以进行SFINAE测试，以确定给定的参数集是否会构造std::vector）。

正如OP和注释所指出的，许多标准库实现只是使用标记调度来转发到更高效、更专业的版本。

感兴趣的是构造函数上下文外部的答案，在这里您可以检测具有特定签名（而不仅仅是兼容性）的函数，并且可以区分不同的函数。我不知道这里的答案，但我有一种（未经验证的）印象，即与标准中描述的确切签名不匹配的函数有时确实会出现在std库中。

相关文章：