自定义分配器作为智能指针向量的替代品？

Question

这个问题是关于拥有指针、使用指针、智能指针、向量和分配器。

我对代码架构的想法有点迷茫。此外，如果这个问题在某个地方已经有了答案，1. 抱歉，我目前还没有找到满意的答案；2. 请指点我。

我的问题如下：

我有几个“东西”存储在一个向量中，以及这些“东西”的几个“消费者”。所以，我的第一次尝试如下：

std::vector<thing> i_am_the_owner_of_things;
thing* get_thing_for_consumer() {
    // some thing-selection logic
    return &i_am_the_owner_of_things[5]; // 5 is just an example
}

...

// somewhere else in the code:
class consumer {
    consumer() {
       m_thing = get_thing_for_consumer();
    }

    thing* m_thing;
};

在我的应用程序中，这将是安全的，因为在任何情况下，“事物”都比“消费者”更长寿。但是，在运行时可以添加更多“东西”，这可能会成为一个问题，因为如果 std::vector<thing> i_am_the_owner_of_things; 被重新分配，所有 thing* m_thing 指针都会变得无效。

解决这种情况的方法是直接存储指向“事物”而不是“事物”的唯一指针，即如下所示：

std::vector<std::unique_ptr<thing>> i_am_the_owner_of_things;
thing* get_thing_for_consumer() {
    // some thing-selection logic
    return i_am_the_owner_of_things[5].get(); // 5 is just an example
}

...

// somewhere else in the code:
class consumer {
    consumer() {
       m_thing = get_thing_for_consumer();
    }

    thing* m_thing;
};

这里的缺点是“事物”之间的记忆连贯性丢失了。可以通过某种方式使用自定义分配器来重新建立这种内存一致性吗？我正在考虑像分配器这样的东西，它总是会为例如 10 个元素分配内存，并且在需要时添加更多的 10 元素大小的内存块。

示例：
最初：
v = ☐☐☐☐☐☐☐☐☐☐
更多元素：
v = ☐☐☐☐☐☐☐☐☐☐ ???? ☐☐☐☐☐☐☐☐☐☐
又一次：
v = ☐☐☐☐☐☐☐☐☐☐ ???? ☐☐☐☐☐☐☐☐☐☐ ???? ☐☐☐☐☐☐☐☐☐☐

使用这样的分配器，我什至不必使用“事物”的std::unique_ptrs，因为在std::vector 的重新分配时间，已经存在的元素的内存地址不会改变。

作为替代方案，我只能考虑通过 std::shared_ptr<thing> m_thing 引用“消费者”中的“事物”，而不是当前的 thing* m_thing，但这对我来说似乎是最糟糕的方法，因为“事物”应该不拥有“消费者”并且使用共享指针我将创建共享所有权。

那么，分配器方法是一种好方法吗？如果是这样，怎么办？我必须自己实现分配器还是现有的分配器？

Answer 1

[共享指针]对我来说似乎是最糟糕的方法，因为“事物”不应拥有“消费者”，而使用共享指针我将创建共享所有权。

那又怎样？也许代码的自文档化程度较低，但它会解决您的所有问题。 （顺便说一句，您使用“消费者”这个词来混淆事物，在传统的生产者/消费者范式中 会取得所有权。）

此外，在当前代码中返回原始指针对于所有权已经完全模棱两可。一般来说，如果可以的话，我会说最好避免使用原始指针（就像你不需要调用delete。）如果你选择unique_ptr，我会返回一个参考

std::vector<std::unique_ptr<thing>> i_am_the_owner_of_things;
thing& get_thing_for_consumer() {
    // some thing-selection logic
    return *i_am_the_owner_of_things[5]; // 5 is just an example
}

Answer 2

如果您能够将thing 视为值类型，请这样做。它简化了事情，您不需要智能指针来规避指针/引用失效问题。后者可以有不同的处理方式：

• 如果在程序期间通过push_front 和push_back 插入新的thing 实例，请使用std::deque 而不是std::vector。然后，不会使该容器中的元素的指针或引用失效（但迭代器会失效 - 感谢@odyss-jii 指出这一点）。如果您担心自己严重依赖 std::vector 的完全连续内存布局的性能优势：创建基准和配置文件。
• 如果在程序过程中在容器中间插入了新的thing实例，请考虑使用std::list。插入或删除容器元素时，不会使指针/迭代器/引用失效。 std::list 的迭代比 std::vector 慢得多，但请确保这是您的场景中的实际问题，然后再过分担心。

Answer 3

IMO 最好的方法是创建新的容器，它的行为是安全的。

优点：

• 更改将在单独的抽象级别上完成
• 对旧代码的更改很少（只需将std::vector 替换为新容器即可）。
• 这将是一种“干净的代码”方式

缺点：

• 看起来可能还有更多工作要做

其他答案建议使用 std::list 来完成这项工作，但分配数量更大，随机访问速度更慢。所以 IMO 最好从一对 std::vectors 组成自己的容器。

所以它可能开始看起来或多或少像这样（最小示例）：

template<typename T>
class cluster_vector
{
public:
    static const constexpr cluster_size = 16;

    cluster_vector() {
       clusters.reserve(1024);
       add_cluster();
    }

    ...

    size_t size() const {
       if (clusters.empty()) return 0;
       return (clusters.size() - 1) * cluster_size + clusters.back().size();
    }

    T& operator[](size_t index) {
        thowIfIndexToBig(index);
        return clusters[index / cluster_size][index % cluster_size];
    }

    void push_back(T&& x) {
        if_last_is_full_add_cluster();
        clusters.back().push_back(std::forward<T>(x));
    }

private:
    void thowIfIndexToBig(size_t index) const {
        if (index >= size()) {
            throw std::out_of_range("cluster_vector out of range");
        }
    }

    void add_cluster() {
       clusters.push_back({});
       clusters.back().reserve(cluster_size);
    }

    void if_last_is_full_add_cluster() {
       if (clusters.back().size() == cluster_size) {
           add_cluster();
       }
    }

private:
    std::vector<std::vector<T>> clusters;
}

这样您将提供不会重新分配项目的容器。它不计量 T 所做的事情。

Answer 4

这个问题没有唯一的正确答案，因为它在很大程度上取决于确切的访问模式和所需的性能特征。

话虽如此，这是我的建议：

继续按原样连续存储数据，但不要存储指向该数据的别名指针。相反，请考虑一种更安全的替代方法（这是一种经过验证的方法），您可以在使用它之前根据 ID 获取指针 - 作为旁注，在多线程应用程序中，您可以锁定尝试调整底层存储的大小，同时这么弱的参考生命。

因此，您的消费者将存储一个 ID，并根据需要从“存储”中获取指向数据的指针。这也使您可以控制所有“获取”，以便您可以跟踪它们、实施安全措施等。

void consumer::foo() {
    thing *t = m_thing_store.get(m_thing_id);
    if (t) {
        // do something with t
    }
}

或者更高级的替代方案来帮助在多线程场景中进行同步：

void consumer::foo() {
    reference<thing> t = m_thing_store.get(m_thing_id);
    if (!t.empty()) {
        // do something with t
    }
}

reference 是一些线程安全的 RAII“弱指针”。

有多种实现方式。您可以使用开放寻址哈希表并使用 ID 作为键；如果您适当地平衡它，这将为您提供大约 O(1) 的访问时间。

另一种选择（最佳情况 O(1)，最坏情况 O(N)）是使用“参考”结构，具有 32 位 ID 和 32 位索引（因此大小与 64-位指针）——索引用作一种缓存。当您获取时，您首先尝试索引，如果索引中的元素具有预期的 ID，您就完成了。否则，您会得到“缓存未命中”，并且您对存储进行线性扫描以根据 ID 查找元素，然后将最后已知的索引值存储在您的参考中。