Copy Stateful Allocator: Semantik des Standard-Bibliotheks-Allocators und interner Speicher

Ich schreibe eine Sammlung von Allokatoren, mit der Absicht, dass sie in Umgebungen mit sehr hoher Leistung verwendet werden sollen. Daher ist ein wenig eingeschränkte Verwendung (vermittelt durch den Compiler, keine Laufzeitfehler) wünschenswert. Ich habe die C ++ 11-Semantik zustandsbehafteter Allokatoren gelesen und wie sie von konformen Containern verwendet werden sollen.

Ich habe einen einfachen Allokator eingefügt, der nur einen Speicherblock innerhalb des Allokatorobjekts enthält. In C ++ 03 war dies illegal.

template <typename T, unsigned N>
class internal_allocator {
private:
    unsigned char storage[N];
    std::size_t cursor;
public:
    typedef T value_type;
    internal_allocator() : cursor(0) {}
    ~internal_allocator() { }

    template <typename U>
    internal_allocator(const internal_allocator<U>& other) {
        // FIXME: What are the semantics here?
    }

    T* allocate(std::size_t n) {
        T* ret = static_cast<T*>(&storage[cursor]);
        cursor += n * sizeof(T);
        if (cursor > N)
            throw std::bad_alloc("Out of objects");
        return ret;
    }
    void deallocate(T*, std::size_t) {
        // Noop!
    }
};

Ist das in C ++ 11 machbar?Was bedeutet es, einen stateful Allokator zu kopieren? Da der Zielcontainer den Kopierkonstruktor für alle Elemente im Quellcontainer aufruft, muss der Speicher im Allokator explizit kopiert werden, oder ist die Standardkonstruktion ausreichend?

Dies führt zu der Frage, welche Werte angesichts der Leistung als Endziel vernünftig sindpropagate_on_container_{copy,swap,move}? Was machtselect_on_container_copy_construction Rückkehr?

Gerne gebe ich auf Anfrage weitere Details bekannt, da dies ein eher nebulöses Problem darstellt - zumindest für mich =)

Diese Behauptung ergibt sich aus der Definition, dass wenna == b kehrt zurücktrue für zwei Instanzen desselbenAllocator Typ, es ist garantiert, dass Speicher mit zugeordneta kann freigegeben werden mitb. Das scheint für diesen Allokator niemals zuzutreffen. Der Standard besagt auch, dass, wenn ein Allokator kopiert wird, wie inA a(b), a == b wird garantiert wahr zurück.

Antworten auf die Frage(1)

Ihre Antwort auf die Frage