一、透明操作符和透明哈希
在C++14引入了透明操作符，而C++20中又引入了透明哈希。它们有一个共同的特征，就是透明。那么它们之间有没有什么联系呢？为什么又引入一个透明哈希呢？一个问题紧跟着一个问题。那咱们就从根儿上盘一盘，把它们的来龙去脉分析一下。这样，就更容易理解透明这个概念以及透明操作符和透明哈希的关系。
二、透明操作符简单说明
透明操作符的本质就是支持异构（透明）的数据操作（当然，必须是库支持的）。由于这种异构的支持，会避免临时对象的创建，也就提高了容器操作的性能。透明操作符针对的是关联容器的特定操作，在库提供的透明类型中，均定义了T::is_transparent标识符（nested type）来表示其是透明类型。其它更详细的可以看一下前面的"透明操作符"相关文章。
透明操作符最明显的就是让开发者可以不用再显式的定义类型从而降低编程的复杂度，再加上临时对象的消除，对性能的提高还是比较明显的。
三、透明哈希
透明操作符是针对有序容器中异构数据操作提供的一种实现。但在STL中，还有无序容器呢？而无序容器中很重要的一个操作就是哈希，所以C++20中就把"黑手"伸向了无序容器中的哈希操作也就是要分析的透明哈希。在STL中std::unordered_set和std::unordered_map等无序容器中，在查找和定位时使用哈希函数可以同样使用类似于透明操作符的方式，这样在保持与C++14兼容的情况下，可以达到类似的效果。不过比较麻烦一些的是，C++20中的透明哈希需要自定义哈希函数。
这样说可能大家不好理解，举一个例子，在std::unordered_map中，虽然其查找的时间复杂度是O(1)。但是如果想通过一个C类型的字符串（const char*）或std::string_view类型的变量来查找以std::string类型为KEY的元素时，标准库会先创建一个临时的std::string对象，然后再查找。
这也意味着虽然查找的本身的动作并没有发生变化，但在准备阶段却进行了意外的对象创建动作。而这也是C++14中透明操作符解决的问题，所以也就可以顺理成章的引入过来，然后把这个问题解决掉。不过，这一引入就到了C++20标准了。
那么为什么在引入这种透明操作之前，C++必须创建一个临时对象呢？其实非常好理解，在C++这种强类型语言中，为了函数操作安全，必须确保操作类型的完全一致（当然也包括隐式的转换）。这在C++中叫做"Homogeneous Lookup"即同质查找。
而在C++20中的无序容器中，为了实现透明哈希，提供了两种基础的透明操作：
- 透明哈希器
一个标准的透明哈希器，需要定义is_transparent标识符；同时，需要提供一个operator()（数据类型转换操作符），它需要支持完全一致的数据类型及可匹配的相关数据类型的参数。这样就可以计算出完全相同的哈希值（KEY）。类似于下面的代码：
c
struct TransparentStr2Hash {
using is_transparent = void; //透明标识符
// std::string
size_t operator()(const std::string& key) const {
return std::hash<std::string>{}(key);
}
// std::string_view
size_t operator()(std::string_view key) const {
// C++17:std::hash<std::string_view>
return std::hash<std::string_view>{}(key);
}
// const char*
size_t operator()(const char* key) const {
return std::hash<std::string_view>{}(key);
}
};- 透明比较器
透明比较器与透明哈希器的处理方式一致辞，也需要要提供上面两种行为。不过对透明比较器来说，有一个优势，在C++14中提供的透明操作符中提供了std::equal_to这个透明操作符。
至此，在标准库中通过透明机制的操作，为开发者提供了更安全高效的API接口。
四、例程
下面看一下这两个函数的具体的例程：
c
#include <iostream>
#include <string>
#include <unordered_map>
struct TransparentStr2Hash {
using is_transparent = void; //透明标识符
// std::string
size_t operator()(const std::string &key) const { return std::hash<std::string>{}(key); }
// std::string_view
size_t operator()(std::string_view key) const {
// C++17:std::hash<std::string_view>
return std::hash<std::string_view>{}(key);
}
// const char*
size_t operator()(const char *key) const { return std::hash<std::string_view>{}(key); }
};
int main() {
std::unordered_map<std::string, int, TransparentStr2Hash, std::equal_to<>> example = {{"one", 1}, {"two", 2}, {"three", 3}};
auto it = example.find("two");//const char*,C++20前需要创建临时string对象
if (it != example.end()) {
std::cout << "Found " << (*it).second << '\n';
} else {
std::cout << "Not found\n";
}
return 0;
}代码只是一个展示，主要是说明C++20标准前的问题。如果大家的环境支持C++20那么可以在"operator()(const char *key)"中下一个断点，如果用C++20调试则断点可以中断，如果用C++17则断点就不会中断了。这也证明了C++20支持了透明哈希。
五、总结
从本文的分析来看，可以很清楚的理解C++标准演进的一种思路。新技术的引进和实践是一步一步的进行的，而不是翻天覆地的革命。其实也很好理解，毕竟标准库已经是一个庞大而稳定的系统，所以其改进必须基于稳妥的前提进行。在连续几个标准中，把相类似的技术引入就是一种非常安全的思路。