我已经设置了一个标准映射来映射一些数字，此时我知道我正在从一个映射到哪些数字，例如：
std::map<int, int> myMap;
map[1] = 2;
map[2] = 4;
map[3] = 6;
但是，稍后，我想将一些数字映射到不在地图中的最低数字，例如：
map[4] = getLowestFreeNumberToMapTo(map); // I'd like this to return 1
map[5] = getLowestFreeNumberToMapTo(map); // I'd like this to return 3
有什么简单的方法吗？
当我将它们添加到地图时，我考虑构建一个有序的数字列表，这样我就可以只查找 1，而不是找到它，使用它，添加它等等。
【问题讨论】：
类似
typedef std::set<int> SetType;
SetType used; // The already used numbers
int freeCounter = 1; // The first available free number
void AddToMap(int i)
{
used.insert(i);
// Actually add the value to map
}
void GetNewNumber()
{
SetType::iterator iter = used.lower_bound(freeCounter);
while (iter != used.end() && *iter == freeCounter)
{
++iter;
++freeCounter;
}
return freeCounter++;
}
如果您的地图很大但很稀疏，这将像 o(log(N)) 一样工作，其中 N 是地图中的项目数 - 在大多数情况下，您不必遍历集合，或者只需几步。 否则，如果地图中的空白很少，那么您最好在 [1..maxValueInTheMap] 范围内拥有一组免费项目。
【讨论】：
在 UNIX 内核中查找最小的未使用数字是一个非常常见的操作，就像每个 open/socket/etc 一样。 syscall 应该绑定到最低的未使用 FD 编号。
在 Linux 上，fs/file.c#alloc_fd 中的算法是：
next_fd，这是一个低水位线——不一定是 100% 准确next_fd = min(fd, next_fd)
next_fd开始搜索位图——lib/find_next_bit.c#find_next_zero_bit是线性的但仍然非常快，因为它需要BITS_PER_LONG一次步幅next_fd = fd + 1
FreeBSD 的sys/kern/kern_descrip.c#fdalloc 遵循同样的思路：从int fd_freefile; /* approx. next free file */ 开始，向上搜索位图。
然而，这些都是在大多数进程打开的FD很少，而很少有数千的假设下运行的。如果数字会变得更高，并且孔洞稀疏，那么常见的解决方案（据我所知）是
#include <algorithm>
#include <functional>
#include <vector>
using namespace std;
int high_water_mark = 0;
vector<int> unused_numbers = vector<int>();
int get_new_number() {
if (used_numbers.empty())
return high_water_mark++;
pop_heap(unused_numbers.begin(), unused_numbers.end(), greater<int>());
return unused_numbers.pop_back();
}
void recycle_number(int number) {
unused_numbers.push_back(number);
push_heap(unused_numbers.begin(), unused_numbers.end(), greater<int>());
}
（未经测试的代码......想法是：保持高水位线；尝试从低于高水位线的unused窃取，否则向上高水位线；返回释放到unused）
如果您的假设是 使用 数字将是稀疏的，那么 Dmitry 的解决方案更有意义。
【讨论】：
我会使用双向地图类来解决这个问题。这样你就可以简单地检查值 1 是否存在等等。
编辑
使用 bimap 的好处是它已经存在健壮的实现，即使搜索下一个空闲数字是 O(n)，如果 n 很大（或者如果 n 适中并且这被非常频繁地调用）。总体上实现了一个不太容易出错且易于维护的简单实现。
如果 n 很大或此操作非常频繁地执行，则值得投入精力实施更高级的解决方案。恕我直言。
【讨论】：