我将在 C++ 中从头开始实现哈希映射作为功能齐全的抽象数据类型。特别是，我将为这个数据容器提供一个迭代器，它能够以识别键的升序遍历所有记录。这部分让我感到困惑，我不知道该怎么做。顺便说一句，通过散列功能，我决定对单向列表使用单独的链接。我想到的一个解决方案是制作另一个列表，该列表将以适当的顺序完全绑定所有元素，该功能将在插入过程本身期间得到保护。但在我看来，它会损害散列本身的许多好处，至少在插入方面；尤其是看看我的ADT的用途，遍历功能会比较少用。长话短说，我应该提供什么样的解决方案？请注意，我不能使用任何专门的库。
笔记：
我知道哈希映射是什么，并且它的学术定义本质上是无序的。也许我应该换个说法，我要构建一个混合的、实用的 ADT，它基本上由一个哈希映射和一些额外的轻量级模块组成，这些模块将提供迭代器功能，这样 ADT 的用户可以从不时按键的升序对记录进行计时。
哈希映射本质上是无序的。这就是为什么它们在 c++ 中通常被命名为 unordered_map。哈希映射的迭代器将访问每个成员一次，但顺序未定义。
在实践中，您可能要么不使用哈希映射，而是使用其他一些关联映射容器，例如红黑树。或者，如果更新很少，您将维护一个并行有序索引。或者，如果更新频繁但遍历很少，则按需生成排序索引。
散列图不是按性质排序的，因为重点是使用散列来知道在哪里存储值。
我可以看到这可能起作用的唯一方法（以性能和现实世界可用性为代价）是如果您保证散列始终在增加，即散列是插入顺序的函数并且它给出有序散列。不过，这只会处理非冲突哈希。您仍然需要以正确的顺序在存储桶中遍历您的列表，因此只需在插入时保持您的列表排序
也许这行不通，这只是一个想法
如果没有，唯一的另一种方法是将所有值存储在排序友好的结构中并从那里迭代。如果您在 hashmap 类中执行此操作，看起来您正在迭代 hashmap，但实际上并非如此。请记住，这种方法会使您在迭代时的内存需求翻倍
让我们知道它是怎么回事，这是一个奇怪的要求