new und delete-Operatoren

PHBU

Hallo,

ich frage mich, in welchen Fällen man den new- bzw. delete-Operator braucht?

Eine Antwort könnte jetzt sein: Weil man damit Speicher dynamisch aufrufen kann.

Kann mir jemand mal ein Code-Beispiel schicken, in dem man new und delete ZWINGEND anwenden muss, damit das Programm richtig bzw. überhaupt funktionieren kann?
Denn wenn man new und delete andauernd verwenden würde, dann würde ein riesiger Code auf einen warten (denn ein neuer Datentyp (Array) muss ja wieder deleted werden).

Danke im Voraus!

MfG

Seikuassi

Nathan

Seikuassi schrieb:

ich frage mich, in welchen Fällen man den new- bzw. delete-Operator braucht?

nie (na gut, fast nie).
Die Operatoren werden von der Standardbibliothek (indirekt) verwendet um dynamisch wachsende Arrays (std::vector), verkettete Listen (std::list) und alle anderen Container zu realisieren, aber als User sollte man mit denen nie (na gut, selten) in Kontakt kommen.

Die Antwort hast du ja bereits selbst (teilweise) gegeben. Immer dann, wenn man Speicher benötigt, dessen Größe zur Laufzeit nicht bekannt ist oder die benötigte Menge über die Stackgrenze hinaus geht.

Die STL bietet jedoch eine gute Auswahl an Containern, welche Dir die Arbeit abnehmen. Nutze sie!

Darüber hinaus gibt es noch smart-pointer. Nutze sie!

In allen anderen Fällen gilt: Zu jedem new ein delete (zu jeden new[] ein delete[]). Soviel Schreibarbeit ist das nun auch nicht.

Ave

PHBU

Hallo Nathan,

Nathan schrieb:

(na gut, fast nie)

Und wann muss man diese Operatoren nun nehmen (soll nicht als provozierend gelten, aber ich würde es nun mal gerne wissen)? Denn new und delete sind ja C++-Style, wenn ich mich nicht irre. malloc und free sind ja C-Style.

Danke im Voraus!

MfG

Seikuassi

Stechus Kaktus schrieb:

In allen anderen Fällen.

Jetzt gibt es doch wirklich keine Fällt mehr, wo du new brauchst, wegen:
-STL Container
-Smart-Pointer
-make_shared
-make_unique

Nathan

Seikuassi schrieb:

Hallo Nathan,

Nathan schrieb:

(na gut, fast nie)

Und wann muss man diese Operatoren nun nehmen (soll nicht als provozierend gelten, aber ich würde es nun mal gerne wissen)?

Für Polymorphie. Da braucht man Zeiger/Referenzen auf Basisklassen, die man mit verschiedenen abgeleiteten Klassen initialisiert. Da nimmt man idR einen std::vector<std::shared_ptr<type>> und initialisiert die dann mit container[i] = new sth. Aber dank Smartptr, braucht man nur new davon, das delete wird automatisch erledigt.

SeppJ

Willst du denn unbedingt alle polymorphen Objekte einzeln auf den Heap legen?

Ich sag nicht, dass das nicht auch mal richtig sein kann, aber es gibt auch andere Methoden. Du brauchst schließlich nur Zeiger/Referenzen, was nicht zwangsläufig new/delete bedeutet.

Du brauchst new, wenn du ein Objekt über den Scope hinaus am Leben erhalten musst, aus welchen Gründen auch immer, z.B. weil du das Objekt nicht kopieren darfst, und deswegen Zeiger hin und her reichst.

dot

Die Frage ist genau so sinnvoll wie "wann muss man den + Operator verwenden?". Wenn du ein Beispiel zum Üben brauchst: Schreib z.B. ein Programm in das der Benutzer so lange verschiedene Wörter eingeben kann, bis er einen . eingibt und danach dein Programm fragen kann, ob ein bestimmtes Wort unter den zuvor eingegebenen Wörter vorkommt oder nicht.

cooky451

Ist deine Frage wozu man Freispeicher allgmein braucht oder warum man new/delete malloc/free gegenüber bevorzugen sollte?

Nathan

SeppJ schrieb:

Willst du denn unbedingt alle polymorphen Objekte einzeln auf den Heap legen?

Ich sag nicht, dass das nicht auch mal richtig sein kann, aber es gibt auch andere Methoden. Du brauchst schließlich nur Zeiger/Referenzen, was nicht zwangsläufig new/delete bedeutet.

Ja, klar.
Aber wenn man die Anzahl vorher nicht kennt, muss man es.
Und das meinte ich auch.

out schrieb:

Jetzt gibt es doch wirklich keine Fällt mehr, wo du new brauchst [...]

Mir fällt jetzt auch kein Beispiel ein, wann ich zuletzt eine pure new-delete-Kombination verwandt habe. Es ist der Vollständigkeit willen aufgeführt. Defensive Consulting sozusagen.

Ave

SeppJ

Nathan schrieb:

Ja, klar.
Aber wenn man die Anzahl vorher nicht kennt, muss man es.
Und das meinte ich auch.

vector und andere Container?

vector<derived_1> derived_1s;
vector<derived_2> derived_2s;

// Erzeuge so viele derived_1 und 2 wie nötig

vector<base*> foo; // Enthält passende Zeiger auf Elemente in derived_1s und derived_2s

SeppJ schrieb:

Nathan schrieb:

Ja, klar.
Aber wenn man die Anzahl vorher nicht kennt, muss man es.
Und das meinte ich auch.

vector und andere Container?

vector<derived_1> derived_1s;
vector<derived_2> derived_2s;

// Erzeuge so viele derived_1 und 2 wie nötig

vector<base*> foo; // Enthält passende Zeiger auf Elemente in derived_1s und derived_2s

Also foo soll Zeiger in dieser Form enthalten?

foo.push_back(&derived_1s[x]);

Ja schön und gut, nur können die ungültig werden, wenn man derived_1s weitere Elemente hinzufügt und der vector umkopieren muss.

Ich finde, die sich hier breitmachende Angst vor jedem new, nimmt Bizarre Formen an. V.a. in Kombination mit Smart-Pointern kann ich nicht ganz nachvollziehen, warum man krampfhaft jedes new vermeiden will.

SeppJ

CreativeLabs schrieb:

Ja schön und gut, nur können die ungültig werden, wenn man derived_1s weitere Elemente hinzufügt und der vector umkopieren muss.

1. Dann nimm eben nicht vector
2. Du weißt als Programmierer genau, wann die Elemente ungültig werden. vector ist in dieser Hinsicht absolut deterministisch.
3. Dazu sind komplexe Datentypen da: Fass alles zusammen. Einfügen mit Reallokation führt zu Aktualisierung der Liste.

Ich finde, die sich hier breitmachende Angst vor jedem new, nimmt Bizarre Formen an. V.a. in Kombination mit Smart-Pointern kann ich nicht ganz nachvollziehen, warum man krampfhaft jedes new vermeiden will.

Dann hast du meine Botschaft nicht verstanden. Es ging mir nicht um new/delete, sondern darum, Nathan ein paar neue Denkanstöße zu geben. Denn: Die Elemente alle gemeinsam im Speicher zu halten ist effizienter.

Indirekt ist das natürlich auch ein Punkt gegen new/delete für Einzelobjekte, da es eben diese Art von Speicherzerhackstückelung fördert. Das gilt aber auch für einige der Container wie z.B. list, die ansonsten kaum Vorteile bieten, die diesen Nachteil zu rechtfertigen.

Nathan

SeppJ schrieb:

Dann hast du meine Botschaft nicht verstanden. Es ging mir nicht um new/delete, sondern darum, Nathan ein paar neue Denkanstöße zu geben. Denn: Die Elemente alle gemeinsam im Speicher zu halten ist effizienter.

Und das ist dir gelungen.
Ich hatte so etwas gar nicht auf dem Plan, schon allein, weil mir das zu viel Arbeit wäre.
Da hätte ich doch tatsächlich so etwas in der Art in einen Allokator gepackt...

SeppJ

Nathan schrieb:

Ich hatte so etwas gar nicht auf dem Plan, schon allein, weil mir das zu viel Arbeit wäre.
Da hätte ich doch tatsächlich so etwas in der Art in einen Allokator gepackt...

Kommt ungefähr auf gleiche raus, aber ich fände meine Methode weniger Arbeit.

SeppJ schrieb:

Kommt ungefähr auf gleiche raus, aber ich fände meine Methode weniger Arbeit.

Deine Methode ist sogar kontraproduktiv.

vector<unique_ptr<base> > foo;

for (int i=0; i<howmany; ++i) {
    foo.push_back(unique_ptr<base>(new derived_1()));
    foo.push_back(unique_ptr<base>(new derived_2()));
}

int sum = 0;
for (int i=0; i<howoften; ++i) {
    for (auto& b : foo) {
        sum += b->foo();
  }
}

http://ideone.com/SV16dd
0.87s

vector<derived_1> derived_1s;
vector<derived_2> derived_2s;

for (int i=0; i<howmany; ++i)
    derived_1s.push_back(derived_1());
for (int i=0; i<howmany; ++i)
    derived_2s.push_back(derived_2());

vector<base*> foo;

for (int i=0; i<howmany; ++i) {
    foo.push_back(&derived_1s[i]);
    foo.push_back(&derived_2s[i]);
}

int sum = 0;
for (int i=0; i<howoften; ++i) {
    for (base* b : foo) {
        sum += b->foo();
  }
}

http://ideone.com/s48f7X
1.60s

deque<derived_1> derived_1s;
deque<derived_2> derived_2s;

for (int i=0; i<howmany; ++i)
    derived_1s.push_back(derived_1());
for (int i=0; i<howmany; ++i)
    derived_2s.push_back(derived_2());

vector<base*> foo;

for (int i=0; i<howmany; ++i) {
    foo.push_back(&derived_1s[i]);
    foo.push_back(&derived_2s[i]);
}

int sum = 0;
for (int i=0; i<howoften; ++i) {
    for (base* b : foo) {
        sum += b->foo();
  }
}

http://ideone.com/Tr7dlD
0.83s

SeppJ

Und, war es schwierig, einen Benchmark so zu manipulieren, dass er genau den einen kleinen Nachteil von vector gegenüber deque übermäßig hervorhebt, ohne dass die Nachteile der deque zum Vorschein kommen?

SeppJ schrieb:

Und, war es schwierig, einen Benchmark so zu manipulieren, dass er genau den einen kleinen Nachteil von vector gegenüber deque übermäßig hervorhebt, ohne dass die Nachteile der deque zum Vorschein kommen?

Wovon redest du?
Die Allokationszeit ist in diesem Benchmark völlig nebensächlich. Es geht um deinen "Trick", die Sachen "kompakt" zu speichern.

Nathan

SeppJ schrieb:

Nathan schrieb:

Ich hatte so etwas gar nicht auf dem Plan, schon allein, weil mir das zu viel Arbeit wäre.
Da hätte ich doch tatsächlich so etwas in der Art in einen Allokator gepackt...

Kommt ungefähr auf gleiche raus, aber ich fände meine Methode weniger Arbeit.

Naja, ich finde einmal Arbeit und initialisieren und dann keinen Mehraufwand, vs Mehraufwand beim Einfügen (jetzt rein codetechnisch) da das erste besser. (Toller Satz)