Smartpointer-Hype vs. Over-Dev

[Nathan]

Das ganze mit den Referenzen und Verweisen kannst du ja beibehalten.
Du hast wohl irgendwo einen Container, der Zeiger hat, wo die Objekte mit new intitialisiert und mit delete zerstört werden. Diese Zeiger ersetzt du durch std::unique_ptr und schon ist das delete automatisiert. Mehr Smartpointer brauchst du nicht.

[Glocke]

Nathan schrieb:

Du hast wohl irgendwo einen Container, der Zeiger hat, wo die Objekte mit new intitialisiert und mit delete zerstört werden. Diese Zeiger ersetzt du durch std::unique_ptr

Naja ich habe mehrere. Kurzer Abriss der Container:

struct GameContext {
    // von factory mit emplace_back befüllt
    std::vector<Dungeon> dungeons;

    Dungeon& createDungeon(...); // dungeon factory
    GameObject* createObject(...); // object factory
};

struct Dungeon {
    struct Cell {
        std::set<GameObject*> objects;
        // und andere Daten pro Tile
    };
    // hier macht unique_ptr sinn, da rein dungeon-intern
    // prinzipiell könnte ein Tile auch nicht vorhanden sein (-> nullptr)
    std::vector<std::unique_ptr<Cell>> cells;

    void spawn(GameObject& object);
    void vanish(GameObject& object);
};

struct GameObject {
    // von setDungeon gesetzt
    Dungeon* dungeon;
    bool is_destroyed; // flag, damit Dungeon das GameObject löschen darf

    void setDungeon(Dungeon& dungeon);
};

wie meinst du das mit den unique pointern genau?

LG Glocke

/EDIT: Oder: Die Factory könnte einen std::unique_ptr<GameObject> liefern, den ich mittels std::move zwischen den Dungeons hin- und herschieben kann *grübel*

[volkard]

Marthog schrieb:

smart pointer verhindern, dass speicher leaked und das auch bei exceptions.

Ich verwende immer smart pointer, wenn das object einen Besitzer hat und meistens ist der klar. Rohe pointer gibt es ja immer noch mit smart_pointer.get() und an Referenzen kommt man auch mit dereferenzieren, da muss man auch aufpassen, dass diese nicht mehr verwendet werden, nachdem das Objekt schon geloescht ist. Nur muss man den Speicher nicht mehr per Hand freigeben, was nicht nur sicherer ist, sondern auch wesentlich uebersichtlicher, weil eben nicht an jedem if ein eigenes delete steht.

Klingt wie "Verwende bitte Smartpointer, ach, ich mags auch nicht begründen.".
Er braucht bei seinem Entwurf keine.

[Marthog]

Bei diesem Design brauchst du keinen smart pointer, weil der Besitzer (also derjenige, der fuer die Speicherfreigabe zustaendig ist) GameContext ist und der hat die Objekte ja bereits im Vector. Der Speicher ist also schon gemanaged und unique_ptr wuerde lediglich eine zusaetzliche indirektion einfuehren, das Design also verschlechtern.
Smartpointer ersetzen lediglich rohe, besitzende pointer, deren Lebenszeit man selber mit new und delete bestimmt.

volkard schrieb:

Klingt wie "Verwende bitte Smartpointer, ach, ich mags auch nicht begründen.".
Er braucht bei seinem Entwurf keine.

Weil er die Objekte direkt im Array speichert. Das ist natuerlich die Beste Methode und funktioniert, solange man nur begrenzt viele verschiedene Typen hat und sicher sein kann, dass der vector zwischendurch seinen Speicherbereich nicht veraendert.
Von diesem Design konnte ich aber vorher nichts wissen.

[Glocke]

Marthog schrieb:

Weil er die Objekte direkt im Array speichert. Das ist natuerlich die Beste Methode und funktioniert, solange man nur begrenzt viele verschiedene Typen hat und sicher sein kann, dass der vector zwischendurch seinen Speicherbereich nicht veraendert.

Was meinst du damit genau: [...] der vector zwischendurch seinen Speicherbereich nicht veraendert[...] ?

[Nathan]

Glocke schrieb:

Marthog schrieb:

Weil er die Objekte direkt im Array speichert. Das ist natuerlich die Beste Methode und funktioniert, solange man nur begrenzt viele verschiedene Typen hat und sicher sein kann, dass der vector zwischendurch seinen Speicherbereich nicht veraendert.

Was meinst du damit genau: [...] der vector zwischendurch seinen Speicherbereich nicht veraendert[...] ?

Nun ein Vector hat intern einen via new oder so angeforderten Speicherblock. Fügst du Elemente ein, wird dieser irgendwann voll. Dann wird ein neuer angefordert, die Elemente rübergemoved und der alte freigegeben. Etwaige Zeiger auf die Elemente zeigen danach natürlich auf den alten Speicherblock und sind somit ungültig.
Anders als bei einem vector von unique_ptr, dort zeigen die Zeiger auf einen eigenen Speicherbereich, der vom vector nicht verändert wird, sondern nur der, wo die Zeiger drin sind. Aber auch bei anderen Datenstrukturen bleiben sie gültig.

[Glocke]

Beziehst du dich damit auf std::vector<Dungeon> dungeons ? D.h. das meine Dungeon-Pointer möglicherweise ungültig werden, wenn sich der Speicherbereich von std::vector ändert?

/EDIT: Ich hatte eh vor std::unordered_map<unsigned short, Dungeon> zu verwenden um die Dungeons mit IDs ansprechen zu können - die unverändert bleiben wenn ich in der Mitte ein's rauswerfen will...

[Nathan]

Glocke schrieb:

Beziehst du dich damit auf std::vector<Dungeon> dungeons ? D.h. das meine Dungeon-Pointer möglicherweise ungültig werden, wenn sich der Speicherbereich von std::vector ändert?

Ja.

/EDIT: Ich hatte eh vor std::unordered_map<unsigned short, Dungeon> zu verwenden um die Dungeons mit IDs ansprechen zu können - die unverändert bleiben wenn ich in der Mitte ein's rauswerfen will...

unordered_map garantiert, dass Pointer gültig bleiben (aber keine Iteratoren!).

[Glocke]

Nathan schrieb:

unordered_map garantiert, dass Pointer gültig bleiben (aber keine Iteratoren!).

Genau das ist die Idee

[hustbaer]

@Glocke
Löscht du jetzt irgend welche Objekte mit delete , oder wird alles über vector/map etc. gemacht?
Denn wenn du irgendwo delete stehen hast, dann ist vermutlich genau das eine Stelle wo du besser nen Smartpointer verwenden würdest.

[Glocke]

hustbaer schrieb:

Denn wenn du irgendwo delete stehen hast, dann ist vermutlich genau das eine Stelle wo du besser nen Smartpointer verwenden würdest.

- Die lifetime eines Dungeons wird komplett vom STL-Container verwaltet - da steht direkt das Dungeon drinne (kein Pointer).
- Bei der lifetime von GameObjects ist es anders: Da diese zwischen Dungeons ausgetauscht werden, löscht das jeweilige Dungeon das Objekt mit delete .

Wie würdest du das Design denn abändern? Der Weg den ich sehe wäre über std::shared_ptr<GameObject> , d.h. immer einen Shared-Pointer zu übergeben. Dann habe ich aber viele (interne) inkrements/dekrements... Allerdings stört mich: ich habe ja keine shared ownership im klassischen Sinne; die ownership wechselt vom einen Dungeon in das nächste.

Im Moment überlege ich, ob ich das GameObject mit std::move zwischen den Dungeons bewege. Bei Calls (die das Objekt nicht "speichern") würde ich dann eine lvalue reference nehmen - oder einen non-owning raw pointer, wenn nullptr semantisch erlaubt sein soll... Bzw. einen std::unique_ptr<GameObject> mit std::move bewegen bzw. eine Referenz auf den Unique-Pointer zu übergeben - dann hätte ich das "null-able" gleich mit..

[hustbaer]

Glocke schrieb:

Allerdings stört mich: ich habe ja keine shared ownership im klassischen Sinne; die ownership wechselt vom einen Dungeon in das nächste.

Dann nimm unique_ptr .
Du musst ja sowieso sicherstellen dass es keinen Zeitpunkt gibt wo nicht genau ein Dungeon existiert der sich zuständig dafür fühlen ein bestimmtes Objekt zu löschen.
Wenn du unique_ptr nimmst wird das nur einfacher - da du die Problemstellen nicht mehr so leicht übersehen kannst.

[Glocke]

hustbaer schrieb:

Wenn du unique_ptr nimmst wird das nur einfacher - da du die Problemstellen nicht mehr so leicht übersehen kannst.

Danke! Mir ist gerade noch etwas klar geworden: Ich habe eine Camera -Klasse die steuert, welcher Bildschirmausschnitt gezeichnet wird. Damit sie dem Spieler folgt, besitzt sie im Moment einen GameObject* raw Pointer.. das wäre mit den Unique Pointern allerdings ein Problem denke ich (oder zumindest kein gutes Design). Allerdings möchte ich auch keine Unique Pointer Referenz in der Camera ablegen - damit ich die Kamera (ggf. später) zwischen zwei Objekten wechseln lassen kann (z.B. um storytechnisch kurz auf einen Boss zu blicken und dann wieder zum Spieler zurück).

Im Grunde bräuchte ich was, das sich einen Unique Pointer merkt, aber auch null sein kann, quasi std::unique_ptr<GameObject>* . Da das aber wiederum nicht schön ist (finde ich zumindest), habe ich überlegt diese "weak reference" zu kapseln, d.h. eine Klasse WeakRef<T> zu schreiben. Was haltet ihr von diesem Ansatz? (Konkrete Implementierung hab ich schon im Kopf - kann ich später ja mal posten).

LG Glocke

[manni66]

Glocke schrieb:

habe ich überlegt diese "weak reference" zu kapseln, d.h. eine Klasse WeakRef<T> zu schreiben. Was haltet ihr von diesem Ansatz? (Konkrete Implementierung hab ich schon im Kopf - kann ich später ja mal posten).

Es gibt schon einen std::weak_ptr, da muss man nichts selber schreiben. Ich bezweifle sowiso, dass du so etwas brauchst. Im Allgemeinen verschwinden Objekte nicht spontan vor der Kamera.

[TyRoXx]

Glocke schrieb:

Damit sie dem Spieler folgt, besitzt sie im Moment einen GameObject* raw Pointer..

Die Kamera muss von irgendjemandem erstellt worden sein. Der hat sich darum zu kümmern, dass der Zeiger gültig bleibt oder die Kamera verschwindet.

[Glocke]

manni66 schrieb:

Es gibt schon einen std::weak_ptr, da muss man nichts selber schreiben.

Afaik existiert std::weak_ptr nur im Kontext von std::shared_ptr .

manni66 schrieb:

Ich bezweifle sowiso, dass du so etwas brauchst. Im Allgemeinen verschwinden Objekte nicht spontan vor der Kamera.

TyRoXx schrieb:

Die Kamera muss von irgendjemandem erstellt worden sein. Der hat sich darum zu kümmern, dass der Zeiger gültig bleibt oder die Kamera verschwindet.

Ich denke wenn ich das ganze event driven aufbaue (was ich ohne hin schon mache und auch weiterhin vor habe - bin gerade am Code Refactoring^^), dann sollte das im Grunde auch kein Problem sein

[my two cents]

Bitte, lese Dir etwas über das RAII (resource acquisition is initialization) durch.

Rohe Pointer als Resource-Owner haben in 99,9% aller Fälle im Code seit C++11 schlicht und ergreifend nichts mehr verloren.

Sie erhöhen die Chance von Fehlern und memory leaks einfach beträchtlich.
Wenn auch noch Exceptions ins Spiel kommen, wird das ganze nur noch schlimmer und garstiger.

Bjarne Stroustrup, Herb Sutter, Scott Meyers und die ganzen C++ Gurus, sowie die Leute vom C++ Standard Committee empfehlen Smartpointer zu verwenden, da sie schlicht ergreifend sicherer sind und von der Performance her rohen Pointern eben würdig sind. Die Sprache hat sich weiterentwickelt und sie ist vor allem sicherer geworden.

Wenn also die klügsten Köpfe in Ihrem Fachgebiet und der Typ der die Sprache "erfunden" hat, Dir sagen benutze bitte diese neue "Verfahren" sollte man vielleicht mal seinen eigenen Standpunkt überdenken und sich fragen ob "Die Welt ist eine Scheibe!" / "Das habe ich schon immer so gemacht!" und "Früher war alles besser!!!" Herangehensweise die Richtige ist.

[TheElevenWay]

Genau, C++14 steht in den Startlöchern und der aktuelle C++ Standard ist seit Jahren C++11. Also nutze diesen auch. Niemand will noch altes C++ programmieren.

[manni66]

Glocke schrieb:

manni66 schrieb:

Es gibt schon einen std::weak_ptr, da muss man nichts selber schreiben.

Afaik existiert std::weak_ptr nur im Kontext von std::shared_ptr .

Ja, wenn man einen unique_ptr "sharen" will, hat man eien shared_ptr, nur in kompliziert und vermutlich fehlerhaft.

[Glocke]

my two cents schrieb:

Bitte, lese Dir etwas über das RAII (resource acquisition is initialization) durch.

Bitte lies dir den bisherigen Thread durch. Sorry, auch wenn es hart klingt - aber ich vermute das hast du bisher nicht getan.

my two cents schrieb:

Rohe Pointer als Resource-Owner haben in 99,9% aller Fälle im Code seit C++11 schlicht und ergreifend nichts mehr verloren.

Sie erhöhen die Chance von Fehlern und memory leaks einfach beträchtlich.
Wenn auch noch Exceptions ins Spiel kommen, wird das ganze nur noch schlimmer und garstiger.

Schön, dass jetzt jemand mit der "Raw Pointer sind Mist"-Keule kommt. Bei RAII geht es eben genau um die Initialisierung und auch die Freigabe! Wenn ich die Speicherverwaltung mit unique Pointern behandle, entspreche ich RAII!

Meine Frage bezieht sich im Moment also nicht auf "owning" Pointer, sondern auf "non-owning" Pointer, d.h. "ich kenne das Objekt, jemand anderes besitzt es aber". Einen rohen Pointer im reinen "non-owning" Context zu verwenden, bringt mir keine Memory Leaks - auch nicht bei ausgelösten Exceptions - die Speicherverwaltung unterliegt immernoch dem RAII. Allerdings habe ich das Problem "ist der Pointer gültig/ungültig" dadurch noch am Hals.

Und nur weil mein Design kein reines Smartpointer-Design ist, sehe ich noch keine ausreichende Begründung, dass es falsch oder veraltet sei.

manni66 schrieb:

Ja, wenn man einen unique_ptr "sharen" will, hat man eien shared_ptr, nur in kompliziert und vermutlich fehlerhaft.

http://en.cppreference.com/w/cpp/memory/shared_ptr
std::shared_ptr is a smart pointer that retains shared ownership of an object through a pointer.

Ich habe aber keine shared ownership in meinem Design. Und "X verwendet Y" heißt nicht, dass X auch zwangsläufig Y besitzen muss!

my two cents schrieb:

Wenn also die klügsten Köpfe in Ihrem Fachgebiet und der Typ der die Sprache "erfunden" hat, Dir sagen benutze bitte diese neue "Verfahren" sollte man vielleicht mal seinen eigenen Standpunkt überdenken und sich fragen ob "Die Welt ist eine Scheibe!" / "Das habe ich schon immer so gemacht!" und "Früher war alles besser!!!" Herangehensweise die Richtige ist.

Lies bitte auch das Startpost noch einmal! Dort habe ich klar gemacht, dass ich meinen Standpunkt überdenken möchte und explizit nach Feedback gefragt. Allerdings macht Feedback (vor allem wenn man ein konkretes Design als Diskussionsgrundlage verwendet) nur dann Sinn, wenn man seine Argumente auch begründet. "Nimm Smartpointer, die Profis nehmen sie doch auch.. Mensch wach endlich auf"-artige Argumentationen sind ... ehrlich gesagt absoluter Mist, sorry wenn ich dir damit zu nahe trete. Aber wirklich konstruktiv ist ein "die anderen"-Argument nie :p