就地初始化风险

Question

Currently, I have a design that maps objects by a key, in an unordered_map . The problem is that in the constructor of this object, I need to look it up by the key- even though it doesn't exist yet. So far I have solved this problem by deferring everything, but it's quite awkward.

So I've been considering a kind of in-place-initializer. Something like

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;
}

This way, code in T's constructor can look it up in the map, even though it's not fully constructed yet.

What are the risks and problems inherent in this design? So far I identified exception safety, the destructor for the unique_ptr is gonna be awkward, as well as the risks of accessing a half-constructed T .

Edit:

Roughly speaking, T represents a node in a graph which is very definitely not acyclic and never will be acyclic, ever. In T's constructor, to calculate some things about T, I wanted to look at T's subnodes- which can contain direct references to that T instance. Imagine something like

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);
}

This obviously doesn't work in the case of cyclic references in K objects. The problem is how I'm going to support them. So far I simply deferred all work so that T simply does not evaluate any potentially referencing code in the constructor, but that leads to some very awkward designs in some places. I wanted to try and place the pointer to the T into the map as it's being constructed, so that circular references evaluate correctly in the constructor and I can throw out this deferred work, as some of it actually has important side-effects (which I cannot avoid due to a third-party design) and managing deferred side-effects is a bitch.

Answer 1

When you have such tight dependencies, in general constructor and destructor easily become a mess.

In general, you should avoid such things. Sometimes, it's just clearer to construct objects in an invalid state, and then initialize them with an initialize method. If you have some instance fields that you would like to be const , you can group them in a non-const struct field with const fields, that it assigned by initialize . You can even define some form of optional which can never be assigned more than once, but maybe that's overshooting.

Getting back to the question, what I see is:

1. The destructor of unique_ptr will call delete on a pointer which was not allocated with new , which is undefined behavior. You should use a unique_ptr with a dedicated/noop deallocator, unless you can control all the code which might remove that thing from the map, and be sure it uses that same release-erase-free boilerplate you used in your catch clause.
2. unique_ptr is meant to also work with incomplete types, so it will not try to access your object, and your T* is segregated inside the function. So you can only access a partially constructed T if:
   • T 's constructor itself leaks a reference (this would be independent from your code here), or
   • Someone other thread tries to lookup for the new item. Doesn't seem to be the case, if your map is also local to the function. If you're doing multithread, then you must change your design, unless performance are not important. Because the only thing to do here is a reentrant mutex lock on the map, which would destroy all benefits you could get from multithreading.

EDIT

In response to your edit. First of all, it seems clean to me. Doesn't look like you're doing something weird. But you have to deal with the destructor problem, because your map will eventually get destroyed (program termination also causes destructors to be called).

Anyway:

1. I think you're using keys in a weird way. If the key itself already contains information about the subnodes, why are you also duplicating that information in the node itself? Information duplication calls for out-of-sync-data bugs.
2. Can't you just change T constructor to check the subkey before the lookup, and avoid looking for its own key ?