wann ist es sinnvoll Objekte mit new zu erzeugen?

otze

objekte werden auch in bäumen aufm heap erzeugt, da man sich das speichern in nem zusätzlichen container nich leisten kann

volkard

objekte werden im freispeicher anelegt, wenn man verschiedene ypen hat, die von einer gemeinsamen basisklasse erben und man diese verschiedenen dinge in einer gemeinsamen liste verwalten will. dann verwaltet man einfach zeiger auf die objekte (und die zeiger sind vom typ Basisklasse*).

Bashar

Sicher?

list<Base*> bl;
Derived1 a, b;
Derived2 c;
bl.push_back(&a);
bl.push_back(&b);
bl.push_back(&c);

DrGreenthumb

Bashar schrieb:

list<Base*> bl;
Derived1 a, b;
Derived2 c;
bl.push_back(&a);
bl.push_back(&b);
bl.push_back(&c);

Das ist aber recht statisch. Will man zur Laufzeit entscheiden welche Objekte angelegt werden sollen, braucht es ein new. Dass und die Situation wo die Objekte länger leben sollen, sind aber auch die einzigen Gründe für new.
Ich versuche jedenfalls immer auf new zu verzichten. Automatische Destruktoren rocken

rüdiger

Automatische Destruktoren rocken

Smart Pointer *hust*

volkard

kingruedi schrieb:

Automatische Destruktoren rocken

Smart Pointer *hust*

?
die leben doch von automatischen destruktoren. warum *hust*?

rüdiger

weil die Aussage von DrGreenthumb von mir so verstanden wurde, dass er new nicht mag, weil man dann keine automatischen Destruktoren hat, sondern mit delete arbeiten muss. Aber mit Smart Pointern ist die Situation ja anders, da hat man new und automatische Destruktoren.

volkard

kingruedi schrieb:

weil die Aussage von DrGreenthumb von mir so verstanden wurde, dass er new nicht mag, weil man dann keine automatischen Destruktoren hat, sondern mit delete arbeiten muss. Aber mit Smart Pointern ist die Situation ja anders, da hat man new und automatische Destruktoren.

ok.
hab geguckt und nichcht gesehen, daß du dich auf "Ich versuche jedenfalls immer auf new zu verzichten. Automatische Destruktoren rocken." bezogen hast, sondern nur auf "Automatische Destruktoren rocken.". daher verstand ich ncht.

DrGreenthumb

"auf new verzichten" ist blöd ausgedrückt. Wenns gebraucht wird, nehme ichs natürlich. Aber bei der Entscheidung hilft mir kein smartpointer.

Bashar

DrGreenthumb schrieb:

Das ist aber recht statisch.

Na und? Ich hab nicht behauptet dass es dynamisch wär. Nur dass Volkards Aussage, polymorphe Listenelemente müssten auf den Freispeicher, nicht richtig ist.

volkard

Bashar schrieb:

DrGreenthumb schrieb:

Das ist aber recht statisch.

Na und? Ich hab nicht behauptet dass es dynamisch wär. Nur dass Volkards Aussage, polymorphe Listenelemente müssten auf den Freispeicher, nicht richtig ist.

wenn du haare spalten magst: ich hab nie gesagt, daß polymorphe objekte auf den freispeicher müssen, ich sagte nur, daß sie dort sind. reine beobachtung. und ich hab nicht gesagt, daß alle polymorphen objekte auf dem freispeicher sind.

Bashar

OK, es ging nicht um "müssen", die Frage war, wann es "sinnvoll" ist. Das ändert aber nichts. Ob es sinnvoll ist, Objekte mit new anzulegen, kann man nicht an Polymorphie oder dem Eintragen der Adresse in Listen festmachen.

volkard

Bashar schrieb:

OK, es ging nicht um "müssen", die Frage war, wann es "sinnvoll" ist. Das ändert aber nichts. Ob es sinnvoll ist, Objekte mit new anzulegen, kann man nicht an Polymorphie oder dem Eintragen der Adresse in Listen festmachen.

wenn ich mal so drüber blicke...

CarstenJ schrieb:

Objekte auf dem Heap werden erzeugt, wenn sie auch nach Verlassen eine Blocks gültig sein sollen.

guter beitrag. es gibt zwar auch die möglichkeit, static vor ne lokale variable zu schreiben, aber oft gibt es andere gründe, die dagegensprechen, und der trick mit dem heap bleibt nur noch übrig.

CarstenJ schrieb:

Objekte auf dem heap werden auch erzeugt, wenn sie eine größe haben sollen, die nicht zur compilezeit festgelegt ist.

guter beitrag. von alloca, üblichen compilererweiterungen mit compilezeitvariablen arraygrößen, erzeugung in fremdspeicher wie dateien oder ähnlichem anzufangen, wäre hier nicht grandios nutzbringend. und oft gibt es andere gründe, die dagegensprechen, und der trick mit dem heap bleibt nur noch übrig.

otze schrieb:

objekte werden auch in bäumen aufm heap erzeugt, da man sich das speichern in nem zusätzlichen container nich leisten kann

guter beitrag. aber leisten kann man sich viel, wenn die randbedingungen schief genug sind. zum beispiel bäume, bei denen immer gilt: wenn ein knoten ein rechtes kind hat, dann hat er auch ein linkes kind. die sollte man in nem array unterbringen, ist billiger als freispeicher. statt zeigern kann man auch arrayindizes nehmen, was den gesamten baum relocable macht. aber wann hat man schonmal nen linksausgefüllten baum, dessen maximalgröße man kennt? oft muss der baum auf dem heap landen.

volkard schrieb:

objekte werden im freispeicher anelegt, wenn man verschiedene ypen hat, die von einer gemeinsamen basisklasse erben und man diese verschiedenen dinge in einer gemeinsamen liste verwalten will. dann verwaltet man einfach zeiger auf die objekte (und die zeiger sind vom typ Basisklasse*).

man könnte aber auch in einer liste objekte polymorphe verwalten, die nicht auf dem freispeicher leigen. aber oft müssen die objekt auf den freispeicher.

es ehrt mich, daß du meinen beitrag herausgesucht hast, um ihn zu verbessern.

Bashar

Es hat nichts mit dir zu tun. Dein Beitrag ist einfach zu High-Level. Das ist ein Fall, bei dem man häufig mit dynamischer Allokation arbeitet ... das läßt sich aber im einzelnen auf die anderen Gründe dafür zurückführen (dynamische Lebenszeit, statisch unbekannte Anzahl von Instanzen, statisch unbekannter Typ ...)

kingsmile

Automatische destruktoren???
ich kann ja mit standard-destruktor was anfangen..
außerdem hat c++Anfänger bestimmt kein wort verstanden(hat keine danke, etc. gepostet).

also kurz und knapp kann mann doch sagen:

mit new werden dynamische objeke auf dem heap erzeugt, die auch noch
vorhanden sind, wenn die funktion verlassen wird.
bei dynamisch erstellten Objecten handelt man eigentlich auch nicht mit dem object als wert, sondern eben mit einem Zeiger auf dieses Object.
(was ja schon bei der deklaration klar wird (obj *MeinObj;)

ohne new werden statische objecte erzeugt die im Stack liegen, und deren
Speicherplatz bei funktionsende eben wieder freigegeben wird. Auch die übergabe eines Solchen Objectes als Funktionsparameter erfolgt als Wert, was bei großen Objecte, geschwindigkeitseinbußen bedeutet.

darüber hinaus wird der speicherbedarf von statichen objecten bereits beim kompilieren errechnet und dieser Speicherplatz zugewiesen. (der stack, auf
dem die Objecte ja dann erzeigt werden ist begrenzt, aber schneller als der
Heap-Speicher, darum quasi diese 'Prüfung').

der zugriff auf fuktionen und methoden dieser objecte unterscheidet sich
ja wohl bitte auch! (obj.func(); -statisch- obj->func();-dynamisch)

auch gilt zu beachten, dass dynamisch erstellt object, die in einem Konstruktor erstellt werden, auch im destruktor wieder gelöscht werden MÜSSEN, da sonst der speicher wärend der Laufzeit nicht wieder freigegeben wird/werden kann.

werden im kostruktor nur statische objecte erstellt, wird deren speicherplatz automatisch vom standard-destruktor wieder freigeben.
(deswegen automatischer destruktor(??))

auch glaube ich zu wissen, dass der zugriff auf statisch erstellte objecte fixer ist(wegen dem Stack), als auf dynamische(Heap).

und Pointerfreaks:
mann kann mit sicherheit auch einen pointer auf statische objecte setzen.
nur zeigt der nach ableben des Objectes leider IRGENDWO hin.
und das für die nutzung polymorpher Klassen dynnamische Objecte benötigt
werden, ist doch eigentlch selbsterklärend, wenn man die Worte
POLYMORPH und DYNAMISCH betrachtet.

also mein tip:
nimm dynamisch objecte.
man muss einfach mit Pointern arbeiten (können).
auch sind dynamische Objecte (besser Pointer auf dynamische objecte) für
fortgeschrittene Programiertechniken voraussetzung.

good luck c++ anfänger.

P.S.:
sollten irgendwelche Pros/Moderatoren/GOSUS einwände haben...
nur zu! ICH lerne gerne immer dazu!

Jester

kingsmile schrieb:

ohne new werden statische objecte erzeugt die im Stack liegen, und deren
Speicherplatz bei funktionsende eben wieder freigegeben wird. Auch die übergabe eines Solchen Objectes als Funktionsparameter erfolgt als Wert, was
bei großen Objecte, geschwindigkeitseinbußen bedeutet.

Nein. Du kannst auch ein dynamisch allokiertes Objekt by value übergeben, oder eins auf dem Stack by reference.

kingsmile schrieb:

der zugriff auf fuktionen und methoden dieser objecte unterscheidet sich
ja wohl bitte auch! (obj.func(); -statisch- obj->func();-dynamisch)

Es geht hier aber um den Unterschied in der Semantik. Oder willst Du jetzt drüber reden, welches der beiden syntaktischen Konstrukte besser ist?

kingsmile schrieb:

werden im kostruktor nur statische objecte erstellt, wird deren speicherplatz automatisch vom standard-destruktor wieder freigeben.
(deswegen automatischer destruktor(??))

Wenn Du den Destruktor selbst implementierst tut er das immer noch. Automatisch deswegen, weil Du ihn nicht von Hand aufrufen mußt (im Gegensatz zum expliziten delete).

kingsmile schrieb:

auch glaube ich zu wissen, dass der zugriff auf statisch erstellte objecte fixer ist(wegen dem Stack), als auf dynamische(Heap).

Da sehe ich prinzipiell erstmal keinen Anlaß dafür. Einzig das anlegen auf dem Stack ist fixer, weil nicht erst nach einem freien Speicherplatz gesucht werden muß.

kingsmile schrieb:

und Pointerfreaks:
mann kann mit sicherheit auch einen pointer auf statische objecte setzen.
nur zeigt der nach ableben des Objectes leider IRGENDWO hin.
und das für die nutzung polymorpher Klassen dynnamische Objecte benötigt
werden, ist doch eigentlch selbsterklärend, wenn man die Worte
POLYMORPH und DYNAMISCH betrachtet.

int * a = new int;
int * b = a;
delete a;

ist das jetzt besser, weil a dynamisch war?

void DoSomething(Printer & printer);

int main()
{
  HtmlPrinter printer;
  DoSomething(printer);
}

polymorph? ja
dynamisch? nein

so what?

kingsmile schrieb:

also mein tip:
nimm dynamisch objecte.
man muss einfach mit Pointern arbeiten (können).
auch sind dynamische Objecte (besser Pointer auf dynamische objecte) für
fortgeschrittene Programiertechniken voraussetzung.

Pointer sind möglicherweise notwendig. Unabhängig davon worauf sie zeigen. Macht es nen unterschied, wohin er zeigt?
Mein Tipp: Stack-Objekte wenn möglich, dynamische wenn nötig. Denn die die auf dem Stack liegen kannst Du beim aufräumen nicht vergessen.

MfG Jester