new int[size] vs std::vector

Immer lieber den standard-Containern. Sie haben klar definierte Kopier-Semantik, sind exception-sicher und richtig befreien.

Wenn du manuell zuweisen, müssen Sie sicherstellen, dass der Freigabe-code wird ausgeführt, und als Mitglieder, Sie müssen schreiben, korrigieren, kopieren, Zuweisung und copy-Konstruktor, der das richtige tut, ohne zu lecken in Ausnahmefällen.

Handbuch:

int *i = 0, *y = 0;
try {
    i = new int [64];
    y = new int [64];
} catch (...) {
    delete [] y;
    delete [] i;
}

Wenn wir wollen, dass unsere Variablen haben nur den Spielraum, den Sie wirklich brauchen, wird es stinkig:

int *i = 0, *y = 0;
try {
    i = new int [64];
    y = new int [64];
    //code that uses i and y
    int *p;
    try { 
        p = new int [64];
        //code that uses p, i, y
    } catch(...) {}
    delete [] p;
} catch (...) {}
delete [] y;
delete [] i;

Oder einfach nur:

std::vector<int> i(64), y(64);
{
    std::vector<int> p(64);
}

Es ist ein horror zu implementieren, die für eine Klasse, die die copy-Semantik. Kopieren kann werfen, kann bei der Zuteilung berücksichtigt zu werfen, und wir wollen, transaktionssemantik, ideal. Ein Beispiel platzen würde diese Antwort tho.

---

Ok hier.

Kopierbar Klasse - Handbuch Ressourcenmanagement vs-Container

Wir haben diesen unschuldigen Blick Klasse. Wie es sich herausstellt, ist es ziemlich böse. Ich fühle mich daran erinnert, American McGee ' s Alice:

class Foo {
public:
    Foo() : b_(new Bar[64]), f_(new Frob[64]) {}
private:
    Bar  *b_;
    Frob *f_;
};

Lecks. Die meisten Anfänger C++ - Programmierer zu erkennen, es fehlt löscht. Hinzufügen:

class Foo {
public:
    Foo() : b_(new Bar[64]), f_(new Frob[64]) {}
    ~Foo() { delete f_; delete b_; }
private:
    Bar  *b_;
    Frob *f_;
};

Undefiniertes Verhalten. Fortgeschrittene C++ - Programmierer erkennen, dass die falschen delete-operator verwendet. Dieses Problem beheben:

class Foo {
public:
    Foo() : b_(new Bar[64]), f_(new Frob[64]) {}
    ~Foo() { delete [] f_; delete [] b_; }
private:
    Bar  *b_;
    Frob *f_;
};

Schlechtes design, Dichtheit und Doppel-löscht lauern dort, wenn die Klasse kopiert wird. Das kopieren selbst ist in Ordnung, der compiler sauber kopiert den Zeiger für uns. Aber der compiler nicht emittieren code zum erstellen von Kopien der arrays.

Etwas mehr erfahrener C++ - Programmierer erkennen, dass die Regel der Drei wurde nicht eingehalten, die besagt, dass, wenn Sie haben explizit geschrieben Destruktor, copy-Zuweisung oder Kopie-Konstruktor, werden Sie wahrscheinlich auch schreiben müssen, die anderen, oder Sie privat ohne Umsetzung:

class Foo {
public:
    Foo() : b_(new Bar[64]), f_(new Frob[64]) {}
    ~Foo() { delete [] f_; delete [] b_; }

    Foo (Foo const &f) : b_(new Bar[64]), f_(new Frob[64])
    {
        *this = f;
    }
    Foo& operator= (Foo const& rhs) {
        std::copy (rhs.b_, rhs.b_+64, b_);
        std::copy (rhs.f_, rhs.f_+64, f_);
        return *this;
    }
private:
    Bar  *b_;
    Frob *f_;
};

Richtig. ... Vorausgesetzt, können Sie garantieren, nie aus der Erinnerung und, dass weder Bar, noch Zerlegen können, nicht auf das kopieren. Spaß beginnt im nächsten Abschnitt.

Das Wunderland zu schreiben, exception-sicheren code.

Bau

Foo() : b_(new Bar[64]), f_(new Frob[64]) {}

• Q: Was passiert, wenn die Initialisierung von f_ ausfällt?
• A: Alle Frobs, die gebaut wurden, sind zerstört. Stellen Sie sich 20 Frob gebaut wurden, die 21 wird scheitern. Als, in LIFO-Reihenfolge, die ersten 20 Frob werden ordnungsgemäß vernichtet.

Das ist es. Bedeutet: Sie haben 64 zombie Bars jetzt. Die Foos Objekt selbst kommt nie zu Leben, der Destruktor wird daher nicht aufgerufen werden.

Wie machen wir diese Ausnahme sicher?

Einen Konstruktor sollte immer erfolgreich komplett oder scheitern komplett. Es sollte nicht sein, die Hälfte live, Hälfte-Toten. Lösung:

Foo() : b_(0), f_(0)
{
    try {    
        b_ = new Bar[64];
        f_ = new Foo[64];
    } catch (std::exception &e) {
        delete [] f_; //Note: it is safe to delete null-pointers -> nothing happens
        delete [] b_;
        throw; //don't forget to abort this object, do not let it come to life
    }
}

Kopieren

Erinnern Sie sich an unsere Definitionen zum kopieren:

Foo (Foo const &f) : b_(new Bar[64]), f_(new Frob[64]) {
    *this = f;
}
Foo& operator= (Foo const& rhs) {
    std::copy (rhs.b_, rhs.b_+64, b_);
    std::copy (rhs.f_, rhs.f_+64, f_);
    return *this;
}

• Q: Was passiert, wenn eine Kopie nicht? Vielleicht Bar kopieren müssen schwere Ressourcen unter der Haube. Es kann scheitern, es wird.
• Einem: An der Zeit-Punkt der Ausnahme, alle Objekte kopiert, so weit wird bleiben wie das.

Dies bedeutet, dass unsere Foo ist nun inkonsistent und unberechenbar Zustand. Geben Sie transaktionssemantik, benötigen wir zum Aufbau des neuen Staates ganz oder gar nicht, und verwenden Sie dann Operationen, die nicht werfen Implantat, der neue Staat in unserem Foo. Schließlich müssen wir bereinigen den Zwischenstand.

Die Lösung ist die Verwendung der Kopier-und swap-idiom (http://gotw.ca/gotw/059.htm).

Erste, wir verfeinern unser copy-Konstruktor:

Foo (Foo const &f) : f_(0), b_(0) { 
    try {    
        b_ = new Bar[64];
        f_ = new Foo[64];

        std::copy (rhs.b_, rhs.b_+64, b_); //if this throws, all commited copies will be thrown away
        std::copy (rhs.f_, rhs.f_+64, f_);
    } catch (std::exception &e) {
        delete [] f_; //Note: it is safe to delete null-pointers -> nothing happens
        delete [] b_;
        throw; //don't forget to abort this object, do not let it come to life
    }
}

Dann definieren wir einen nicht-werfen-swap-Funktion

class Foo {
public:
    friend void swap (Foo &, Foo &);
};

void swap (Foo &lhs, Foo &rhs) {
    std::swap (lhs.f_, rhs.f_);
    std::swap (lhs.b_, rhs.b_);
}

Nun können wir unsere neue exception-sichere copy-Konstruktor und der Ausnahme-safe-swap-Funktion schreiben, die eine exception-sichere copy-Zuweisung-operator:

Foo& operator= (Foo const &rhs) {
    Foo tmp (rhs);     //if this throws, everything is released and exception is propagated
    swap (tmp, *this); //cannot throw
    return *this;      //cannot throw
} //Foo::~Foo() is executed

Was ist passiert? Zuerst bauen wir neue Speicher und kopieren rhs' in es. Dies kann werfen, aber wenn es funktioniert, unser Staat wird nicht verändert und bleibt das Objekt gültig ist.

Dann tauschen wir unsere Eingeweide mit dem temporären Eingeweiden. Die temporären bekommt, was nicht mehr benötigt wird, und gibt das Zeug am Ende des Bereichs. Wir haben effektiv verwendet tmp wie eine Mülltonne, und richtig wählen, RAII wie die Müllabfuhr.

Möchten Sie vielleicht zu schauen, http://gotw.ca/gotw/059.htm oder Lesen Exceptional C++ für weitere Informationen über diese Technik und über das schreiben von exception-sicheren code.

Setzen Sie zusammen

Zusammenfassung von dem, was kann nicht werfen oder ist nicht erlaubt zu werfen:

• kopieren primitive Typen schmeißt
• Destruktoren sind nicht erlaubt zu werfen (weil sonst, exception-sicheren code zu haben, würde nicht möglich sein, überhaupt)
• swap Funktionen müssen nicht werfen** (und C++ - Programmierer als auch die gesamte standard-Bibliothek erwarten, dass es nicht zu werfen)

Und hier ist endlich unsere sorgfältig gestaltete, exception-safe, korrigierte version von Foo:

class Foo {
public:
    Foo() : b_(0), f_(0)
    {
        try {    
            b_ = new Bar[64];
            f_ = new Foo[64];
        } catch (std::exception &e) {
            delete [] f_; //Note: it is safe to delete null-pointers -> nothing happens
            delete [] b_;
            throw; //don't forget to abort this object, do not let it come to life
        }
    }

    Foo (Foo const &f) : f_(0), b_(0)
    { 
        try {    
            b_ = new Bar[64];
            f_ = new Foo[64];

            std::copy (rhs.b_, rhs.b_+64, b_);
            std::copy (rhs.f_, rhs.f_+64, f_);
        } catch (std::exception &e) {
            delete [] f_;
            delete [] b_;
            throw;
        }
    }

    ~Foo()
    {
        delete [] f_;
        delete [] b_;
    }

    Foo& operator= (Foo const &rhs)
    {
        Foo tmp (rhs);     //if this throws, everything is released and exception is propagated
        swap (tmp, *this); //cannot throw
        return *this;      //cannot throw
    }                      //Foo::~Foo() is executed

    friend void swap (Foo &, Foo &);

private:
    Bar  *b_;
    Frob *f_;
};

void swap (Foo &lhs, Foo &rhs) {
    std::swap (lhs.f_, rhs.f_);
    std::swap (lhs.b_, rhs.b_);
}

Vergleichen, dass unsere anfängliche, unschuldige auf der Suche code ist böse bis auf die Knochen:

class Foo {
public:
    Foo() : b_(new Bar[64]), f_(new Frob[64]) {}
private:
    Bar  *b_;
    Frob *f_;
};

Du besser nicht noch mehr Variablen. Früher oder später werden Sie vergessen, hinzuzufügen richtigen code an einem bestimmten Ort, und Ihre ganze Klasse krank wird.

Oder machen Sie es nicht-kopierbar.

class Foo {
public:
    Foo() : b_(new Bar[64]), f_(new Frob[64]) {}
    Foo (Foo const &) = delete;
    Foo& operator= (Foo const &) = delete;
private:
    Bar  *b_;
    Frob *f_;
};

Für einige Klassen ist dies sinnvoll (streams, für eine Instanz; zu teilen streams, explizit mit std::shared_ptr), aber für viele ist es nicht.

Die wirkliche Lösung.

class Foo {
public:
    Foo() : b_(64), f_(64) {}
private:
    std::vector<Bar>  b_;
    std::vector<Frob> f_;
};

Diese Klasse hat sauber das kopieren der Semantik, ist exception-sicher (Sie erinnern sich: als Ausnahme sicher, bedeutet nicht, nicht zu werfen, sondern um keine Lecks und möglicherweise haben transaktionssemantik), und nicht Leck.

Ich glaube nicht, dass es jemals einen Fall, wo new int[size] vorzuziehen ist. Sie werden manchmal sehen Sie es in der pre-standard-code, aber selbst dann glaube ich nicht, es wurde immer eine gute Lösung; in der pre-standard-Tage, wenn Sie nicht über ein äquivalent zu std::vector in Ihrer tool-kit, Sie schrieb einer. Die einzigen Gründe, die Sie möglicherweise verwenden möchten, ein new int[size] ist bei der Durchführung eines pre-standard-vector-Klasse. (Meine eigene getrennte Zuweisung und Initialisierung, wie die Container in der standard-Bibliothek, aber dies möglicherweise overkill für ein sehr einfaches Vektor-Klasse.)

Intern der Vektor genau das gleiche tun auch wird es kümmern, den Speicher freizugeben. Es gibt also keinen Grund für die Verwendung des new-operators. std::vector ist ein Teil von c++, es ist standard, dass es geprüft wird und es sicher ist, nicht die raw-pointer, wenn Sie haben einige standard-Weg, um Ihre Arbeit zu erledigen.

Kann jemand mir einen Rat geben, welche ist besser?

Vektor ist besser, wenn

1. Sie noch nicht gelernt haben, zu tun die manuelle Speicherverwaltung.
2. Sie gelernt haben, aber sind nicht überzeugt, dennoch.
3. Sie denken, Sie wissen, wie es zu tun, aber unwissentlich übermütig.
4. Sie wirklich wissen, was Sie tun, aber einen Fehler machen könnte.
5. Sind Sie ein-guru und keine der oben genannten zutrifft, aber der code könnte sich später gepflegt von einem Kollegen, für die alle der oben genannten gilt.

...

1. Ziemlich immer.

---

Manuelle Speicherverwaltung können leicht und oft führt zu Speicherverlusten, und-schlimmer noch Undefiniertes Verhalten.