阅读节点句柄的文档,我注意到节点句柄类型的许多功能可以简单地通过
std::unique_ptr
的专门化来模拟。事实上,节点句柄类型的功能与 std::unique_ptr
的功能非常相似。它只有一个更符合关联容器特性的接口,例如 key_type
和 mapped_type
别名以及获取键/映射值引用的函数。
因此该标准引入了节点句柄类型,而不是简单地将
std::unique_ptr
专门化为 node_type
,还有其他优点吗?
从纯粹的哲学角度来看,仅仅因为一种类型与另一种类型具有相似的接口并不意味着该类型是多余的并且应该被更通用的类型取代。
在这种特殊情况下,类型并不等同。
node_handle
的主要目标之一是您不知道容器使用的节点的实际类型。甚至不能作为不透明的类型别名; node_type
是 node_handle
的特化,而不是内部节点类型名称。
另外,请考虑
unique_ptr
就其本质而言,包装了指向某物的指针。有一个指针在某个时刻不被拥有,然后 unique_ptr
拥有它。因此,release
是一个合理的函数:它否认指针而不破坏它。
这对于
node_handle
来说不是一个合理的函数。您没有创建该节点,因此您没有能力销毁它。该节点由一个故意对用户不透明的系统拥有。它持有的任何指针都指向实现定义的数据结构,并且可能有多个。
但这忽略了
node_handle
的关键特征,即它存在的原因。 node_handle
的要点是,您可以从这样的容器中提取元素,修改其键(从而影响它在容器中的位置),然后重新插入它而不分配内存。要使用 unique_ptr<T>
做到这一点,需要 T
是用户理解并且可以与之交谈的某种类型(因此用于修改密钥)。那么,什么是T
?
容器不能是
value_type
,因为这使得密钥类型为 const
,因此不可修改。因此它必须是某种新类型,为您提供修改键值的接口。因为无论如何它都必须是某种新类型...你不妨只制作 node_handle
那种类型,这样可以省去很多痛苦。
此外,还需要考虑分配器行为。首先,
node_handle
还存储容器分配器的副本。 unique_ptr
确实做不到。
其次,当您从一个容器移动分配到另一个容器时,有状态分配器可能会具有特殊行为。具体来说,您可能需要在执行此操作时移动分配器。但对于许多分配者来说,你可能不会。因此,
node_handle
需要复制这种行为。 unique_ptr
也做不到。
现在,您基本上可以通过使用符合上述内容的不同接口创建
unique_ptr
的专业化,通过使用隐藏(特定于容器的)类型名称作为模板参数来实现所有这些。但是……为什么要麻烦呢?这是一个不同的界面,具有不同的专门用途。
所以已经给它自己的类型名了。 C++ 的名字还没有用完。