spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BlueCobold«

Zitat von »dot«

aber new verwendet man sowieso selten und wenn, dann niemals mehr direkt...

Damit bist Du schon der zweite, der das sagt. Ich frage mich wie genau es dann läuft. Beispiele? Gerade bei Polymorphie fällt mir da kein so richtiger Weg rundrum ein.

Polymorphie ist erstmal völlig unabhängig davon, wie die Objekte erzeugt werden. Ich habe in meinen Programmen regelmäßig Objekte am Stack, die dann polymorph verwendet werden. Ich würde sogar fast soweit gehen, das eher als Regelfall, denn als Ausnahme zu bezeichnen...

Zitat von »David Scherfgen«

Wahrscheinlich meint er std::make_shared!

In der Tat, wobei ich eher an make_unique und ähnliches denke, shared_ptr ist vergleichsweise selten wirklich angebracht...

Zitat von »BlueCobold«

Auf den Stack legen dürfte in vielen Fällen nur bedingt funktionieren. Jedenfalls in den üblichen Fällen, wo ich Objekte dynamisch anhand von Level-Files/Daten erzeuge.

In solchen Fällen hat man es meiner Erfahrung nach allerdings meist direkt mit Collections von Objekten zu tun, wo ich dann einen entsprechenden Container verwenden würde. Dass wirklich mal einzelne Objekte dynamisch erzeugt werden müssen, kommt bei mir eher selten vor...

Im diesem Fall ist es nicht nötig, da es sowieso Kopien sind, die übergeben werden. Man kann es aber auch machen, wenn man nicht möchte, dass die Funktion fälschlicherweise die Variable verändert.
Ansonsten macht man das bei Funktionen oft, wenn man eine Referenz übergibt, welche nicht verändert werden darf (und nur als const Referenz übergeben wird zu Optimierungszwecken, damit keine Kopie gemacht werden muss).

Man sieht das eher bei Strings, auf welche lesend zugegriffen werden muss in der Funktion.

Bei const gilt: Lieber einmal zu viel, als zu wenig. Wegnehmen kann man es nachher immer noch, wenn es keine gute Idee war etwas const zu machen.

const ist eigentlich nie und an keiner Stelle nötig. Möglicherweise kann der Compiler dank const ein paar Sachen mehr Optimieren, aber darum geht es überhaupt nicht.
const ist einfach dafür da, dem Programmierer zu helfen, sein Programm übersichtlicher und robuster zu gestalten. Im Grunde ist es das selbe wie mit öffentlichen (public) Klassenattributen: Man muss sie nicht benutzen, es hilft aber.
Ein Beispiel: Die std::string Klasse bietet die Funktion c_str() an, die dir einen konstanten C-String liefert. Den kannst du zum lesen benutzen, du darfst ihn aber nicht verändern. Man könnte jetzt auf die Idee kommen, einen std::string über seinen C-String zu manipulieren. Aber möglicherweise ist das, was c_str() dir liefert nur eine Darstellung des Strings. Möglicherweise teilen sich 2 gleiche Strings den selben Speicher und erst wenn du den einen veränderst, bekommt er seinen eigenen Speicher. Über die Zugriffsmethode von std::string kann man das problemlos realisieren, aber die Klasse kann einfach nicht mitbekommen, wenn das, was sie als C-String liefert, verändert wird.

Im Grunde genommen, sagt ein const einfach nur "Wenn du das hier änderst, hat es nicht den Effekt, den du erwartest, also verbiete ich es dir, damit du dir einen vernünftigen Weg suchst, das zu tun, was du wirklich tun willst".

Ein zweiter Effekt ist, dass man die Programmkomplexität verringert, indem man durch const sicherstellt, dass etwas nicht verändert werden kann. Es ist ein bisschen wie mit globalen Variablen: Wenn man etwas von jeder Stelle im Code aus verändern kann, wird das Programm unübersichtlich und schwerer zu debuggen. Mit const hingegen kannst du lesenden Zugriff gewähren (der meiste wesentlich weniger problematisch ist), ohne jedesmal eine Kopie anlegen zu müssen (damit das Original auch ja nicht verändert wird). Deshalb empfiehlt es sich, const überall dort zu benutzen, wo es möglich ist.

Zitat von »dot«

In solchen Fällen hat man es meiner Erfahrung nach allerdings meist direkt mit Collections von Objekten zu tun, wo ich dann einen entsprechenden Container verwenden würde.

Und das wäre dann was für einer, wenn Du die Objekte nicht im Heap erstellen und polymorph einen Obertyp verwenden willst?
Typisches Beispiel: XML. Das XML wird geladen und für jeden der verschiedenen Objekt-Typen darin baut man eine Methode, die das XML für diesen Typ parsen und dann eine Instanz des Typs zurückgeben kann. Diese sollen dann polymorph in einer Collection verwendet werden. Wie würdest Du das dann umsetzen?

Ich kann auch einen Container für jeden konkreten Typ haben und die Objekte da drin dann trotzdem polymorph verwenden, wenn nötig. Um Objekte in Container zu packen, brauch ich keine Polymorphie. Die Besitzer von Objekten kennen meiner Erfahrung nach meistens deren konkreten Typ...

Das war überhaupt nicht die Frage. Lies sie bitte noch einmal. Alle erzeugten Objekte sollen in denselben Container, der nur ihren Interface-Typ, aber nicht die konkrete Implementierung kennt. Jede konkrete Implementierung wird in einer Methode geparsed und ein Objekt davon erzeugt.

Zitat von »BlueCobold«

Alle erzeugten Objekte sollen in denselben Container, der nur ihren Interface-Typ, aber nicht die konkrete Implementierung kennt.

Das ist eine Mögliche Lösung, aber eben nicht die einzige. Ich sehe keinen zwingenden Grund, wieso hier alle Objekte unbedingt in den selben Container müssen!?

Was ist, wenn man zur Compile-Zeit noch gar nicht weiß, welche Typen es gibt? Dann fällt die "Ein Container pro Typ"-Lösung ja schonmal raus.
Das kommt z.B. vor, wenn man Objekt-Factories über DLLs nachlädt.