Objeke referenzen gebrauch, wie object copy vermeiden?
-
@patrickm123 das andere, wichtigere Problem ist aber auch, dass nun das o-Objekt komplett von dem a-Objekt, mit dem es erzeugt wurde, abhängt. Das heißt, wenn jemand das a ändert, ist es in deinem o auch geändert. Wenn jemand das a-Objekt löscht, ist deine o-Objekt kaputt (die Referenz ist ungültig).
-
@It0101 danke für den Hinweis mit dem Aufräumen - die pointer variante hatte ich deshalb genommen, weil ich dynamisch Objekte in S anlegen wollte, ohne Objekte zu kopieren, es ist eher eine Lernübung. In einem "richtigen" Programm würde ich wohl Memory profiling machen müssen?
-
@wob danke, interessanter Punkt, dass mit dem Löschen wäre nicht so gut.... d.h. müsste man dann schauen wie man es z.B. über tests garantieren kann, dass das Programm ein gültiges a enthält
-
nein man müsste sein programmdesign so aufstellen, dass so etwas nicht vorkommen kann..........
-
im destructor, sollte ich auf "pointer is not null" checken bevor ich delete aufrufe?
-
Nein, solltest du nicht.
delete
funktioniert auch auf Nullpointern.
-
@patrickm123 sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
im destructor, sollte ich auf "pointer is not null" checken bevor ich delete aufrufe?
Es darf nur nicht uninitialisiert sein bzw nicht "schon mal vorher deleted".
-
@patrickm123 sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
@It0101 danke für den Hinweis mit dem Aufräumen - die pointer variante hatte ich deshalb genommen, weil ich dynamisch Objekte in S anlegen wollte, ohne Objekte zu kopieren, es ist eher eine Lernübung. In einem "richtigen" Programm würde ich wohl Memory profiling machen müssen?
Du solltest nicht panische Angst vor dem Kopieren haben. Du musst dir bei deinem Design vor allem darüber klar sein, wem was gehört.
Deswegen wäre es z.B. unüblich, ein Objekt auf dem Heap ( z.B. mit new erzeugt ), dass Klasse A gehört, einer anderen Klasse B als rohen Pointer zu übergeben, die mit Klasse A rein gar nichts zu tun hat. In dem Fall wäre eine Kopie durchaus in Ordnung. Oder ein alternatives Konzept wie "shared_ptr". Aber der Fokus sollte immer auf den Besitzverhältnissen liegen. Der Besitzer einer Ressource erzeugt sie und zerstört sie im Idealfall auch wieder. Und wenn die Ressource weitergeben wird ( aus A entfernt und nach B übergeben ), dann gibt es auch dafür wieder bessere Varianten als reine Pointer. Z.B. std::unique_ptr und/oder move-Semantik.Aus meiner Sicht ist die Nutzung von reinen Pointer eine absolute Notlösung wenn alle anderen Konzepte nicht tragbar sind.
-
@It0101 sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
Aus meiner Sicht ist die Nutzung von reinen Pointer eine absolute Notlösung wenn alle anderen Konzepte nicht tragbar sind.
Das gilt für rohe besitzende pointer.
-
@Swordfish Findest du denn "geborgte" Zeiger als Membervariablen OK? Ich ehrlich gesagt kaum jemals. Das wird so schnell so unübersichtlich was die Lifetimes angeht...
-
@hustbaer Meine Ergänzung bezog sich wirklich nur auf die zitierte allgemeine Aussage. Ich kann es halt nicht mehr sehen, daß Pointer allgemein phöse sind.
-
@It0101 sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
Klasse A rein gar nichts zu tun hat. In dem Fall wäre eine Kopie durchaus in Ordnung. Oder ein alternatives Konzept wie "shared_ptr". Aber der Fokus sollte immer auf den
danke - ok wer/was mit ressourcen macht/erzeugt hilft dem verständnis. das ist auch anders als in anderen programmiersprachen, wo es nur referenzen gibt
-
@Swordfish sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
@hustbaer Meine Ergänzung bezog sich wirklich nur auf die zitierte allgemeine Aussage. Ich kann es halt nicht mehr sehen, daß Pointer allgemein phöse sind.
OK, sehe ich genau so.
Speziell wenn man doch "geborgte" Pointer hat finde ich es greislich wenn der Konstruktor dann ne Referenz nimmt (und sich dann die Adresse des Objekts merkt) - nur weil der Pointer nicht NULL sein darf. *schauder*
Weil's bei der Verwendung halt sonst immer nach "by value" Semantik aussieht und wenn das dann gelogen is dann is schnell aua.
-
@hustbaer sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
dann is schnell aua.
Noch schneller Aua:
struct foo_t; { int *value; foo(const int &value) : value{ &value } {} } // ... foo_t foo{ int{ 42 } };
hehe.
-
@Swordfish sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
@It0101 sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
Aus meiner Sicht ist die Nutzung von reinen Pointer eine absolute Notlösung wenn alle anderen Konzepte nicht tragbar sind.
Das gilt für rohe besitzende pointer.
Ich sag ja nicht, dass es generell "phöse ist". Aber in den meisten Fällen, sind eben Smart-Pointer oder sogar die Nutzung der Move-Semantik eine "elegantere" Lösung, die sowohl die Wartbarkeit verbessert als auch die Fehlerquote reduziert.
Das Herumreichen von Pointern ist natürlich im Hinblick auf die Performance nicht zu toppen, birgt aber viele Risiken. Insbesondere wenn man was hübsches mit Pointern gebaut hat und dann ein halbes Jahr später daran weiterarbeitet und nicht mehr so genau im Hinterkopf hat, wem was gehört und wer wie wann wo etwas zerstören soll oder wie es sich mit der Lifetime verhält.
-
@It0101 sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
nicht mehr so genau im Hinterkopf hat, wem was gehört und wer wie wann wo etwas zerstören soll oder wie es sich mit der Lifetime verhält.
Dann lies meine Ergänzung bitte nochmal.
-
@Swordfish sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
@hustbaer sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
dann is schnell aua.
Noch schneller Aua:
struct foo_t; { int *value; foo(const int &value) : value{ &value } {} } // ... foo_t foo{ int{ 42 } };
hehe.
wer macht denn sowas? Das sieht ja gefährlich aus.
-
@It0101 Gepeinigten Bären fallen da sicher Kandidaten ein.
-
@Swordfish @It0101
Mitconst
müsste ich nachsehen, aber ohneconst
... ja, sicher, dauernd. Also nicht ich, aber halt ... Leute die Code geschrieben haben mit dem ich dann arbeiten durfte.Und ich finde es ohne const schon schlimm genug, da könnte man genau so leicht sowas schreiben:
unique_ptr<Foo> makeFoo(...) { SomeThingyThatFooSeemsToNeed thingy{ ... }; return make_unique<Foo>(thingy); }
Bzw. oft ist es nicht so klar und einfach, oft ist das "Thingy" auch irgend ein Member von Irgendwas, nur dass das Irgendwas halt nicht lange genug lebt. Ohne "&" hat man da halt schnell übersehen dass
Foo
sich evtl. die Adresse von dem "Thingy" merken könnte. Speziell wenn man Code liest anstrengend weil man nie weiss ob jetzt Value-Semantik gemeint ist oder Pointer-Semantik.
-
@hustbaer sagte in Objeke referenzen gebrauch, wie object copy vermeiden?:
Leute die Code geschrieben haben mit dem ich dann arbeiten durfte.
steinigen.