就地初始化风险

目前，我有一个通过unordered_map中的键映射对象的设计。问题是，在这个对象的构造函数中，我需要按键查找它——尽管它还不存在。到目前为止，我已经通过推迟一切来解决这个问题，但这很尴尬。

所以我一直在考虑一种就地初始化器。类似的东西

std::unordered_map<K, std::unique_ptr<T, FunkyDeleter>> map;
T* ptr = malloc(sizeof(T));
map[key] = std::unique_ptr<T, FunkyDeleter>(ptr);
try {
    new (ptr) T(args);
} catch(...) {
    map[key].release();
    map.erase(key);
    free(ptr);
    throw;
}

这样，T的构造函数中的代码可以在映射中查找它，即使它还没有完全构造好。

这种设计固有的风险和问题是什么？到目前为止，我已经确定了异常安全性，unique_ptr的析构函数将很尴尬，以及访问半构建的T的风险。

编辑：

粗略地说，T表示图中的一个节点，它绝对不是非循环的，也永远不会是非循环的。在T的构造函数中，为了计算关于T的一些内容，我想看看T的子节点——它可以包含对该T实例的直接引用。想象一下类似的东西

struct K {
    std::vector<K*> subkeys;
};
class T {
    std::vector<T*> child_nodes;
public:
    T(K* key, graph& graph) {
        for(auto subkey : keys->subkeys)
            child_nodes.push_back(graph.get(subkey));
    }
    std::vector<T*> children() { return child_nodes; }
};
class graph {
    std::unordered_map<K*, std::unique_ptr<T>> nodes;
public:
    T* get(K* key) {
        if (nodes.find(key) == nodes.end())
            nodes[key] = std::unique_ptr<T>(new T(key, *this));
        return nodes[key].get();
    }
};
int main() {
    graph g;
    K key1;
    K key2;
    key1.subkeys.push_back(&key2);
    key2.subkeys.push_back(&key1);
    g.get(&key1);
}

这在K对象中循环引用的情况下显然不起作用。问题是我将如何支持他们。到目前为止，我只是推迟了所有的工作，这样T就不会在构造函数中评估任何潜在的引用代码，但这会在某些地方导致一些非常尴尬的设计。我想在构建T时尝试将指向它的指针放在映射中，这样循环引用就可以在构造函数中正确评估，我可以放弃这些延迟的工作，因为其中一些实际上有重要的副作用（由于第三方设计，我无法避免），而管理延迟的副作用是一件很麻烦的事。