spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Evrey«

Referenzen verweisen hingegen immer auf ein gültiges Objekt.

Das stimmt so aber auch nicht.
Was hält mich davon ab, eine Referenz auf ein mit new erzeugtes Objekt zu erzeugen, welches ich dann lösche?

Zitat von »David Scherfgen«

Zitat von »Evrey«

Referenzen verweisen hingegen immer auf ein gültiges Objekt.

Das stimmt so aber auch nicht.
Was hält mich davon ab, eine Referenz auf ein mit new erzeugtes Objekt zu erzeugen, welches ich dann lösche?

Ach, geht doch noch viel simpler:

Normale Referenzen in C# können null sein.
T? ist nur ein Shortcut für Nullable<T>, welches es erlaubt, auch Werttypen (z.B. int) auf "null" zu setzen.

Außerdem...

• Referenzen sind unveränderbar, Zeiger können jederzeit einem neuen Wert zugewiesen werden.
  
• Zeiger sind erforderlich um Speicher dynamisch zu verwalten.
  

Theoretisch könnten Zeiger Referenzen rein von der Funktionalität eher ersetzen(Siehe C) als andersrum.
Referenzen sind so in etwa "konstante Zeiger mit integrierter Dereferenzierung" und sind für den saubereren Syntax notwendig.
Ganz besondere spezielle Rolle spielen sie aber auch nochmal bei der Move-Semantik.

Null-Referenzen dürfte es in einem C++ Programm wohl nicht geben, weil wie Evrey schon sagte, sie scheinbar undefined Behavior sind. Praktisch kann es sie theoretisch natürlich geben, sollte es jedoch trotzdem nicht.

Zitat von »dot«

Mindestens genau so wichtig, wenn nicht sogar wichtiger ist allerdings die Frage, wieso man überhaupt gerade etwas am Heap allokieren will...

Also mir ist ja klar, dass man Variablen am Stack schneller anlegen kann als am Heap. Aber was ich mich frage ist, wie man weitestgehend auf den Heap verzichten können soll.
Sagen wir ich habe eine dynamische Anzahl an Spielobjekten. Dann führt im Grunde kein weg daran vorbei, dass sie am Heap landen. Außerdem würde ich sie im Normalfall in einen std-Container packen, und da werden Objekte nunmal hin und her kopiert. Also nehme ich einen Container mit std::uniqu_ptr, weil ich keine Lust habe, komplexe Objekte zu kopieren. Aber selbst wenn ich keine Zeiger im Container hätte, da er dynamisch alloziert ist, wären die Objekte doch so oder so am Heap. Was wäre also dein Vorschlag?

Zu shared_ptr: Benutze ich eigentlich nie. Wenn ein Objekt von mehreren anderen Objekten benutzt wird, kann man meistens eines davon als den Besitzer ausfindig machen, dieser hat dann einen unique_ptr, während die anderen dann nur einen normalen raw-pointer benutzen. Oder halt eine Referenz. Es muss nur sichergestellt sein, dass der Besitzer länger lebt als alle Benutzer, aber das ist in der Regel sehr einfach.
Das schöne an unique_ptr ist dann auch, dass du explizit modellierst, wer Besitzer und wer Benutzer ist. Und wenn du Zeiger an Funktionen übergibst, siehst du schon an der Deklaration, ob das Objekt den Besitzer wechselt oder nicht. Wenn du das konsequent machst, kannst du garantieren, dass jedes dynamisch erzeugte Objekt immer genau einen Besitzer hat und auch garantiert freigegeben wird, sobald es nicht mehr benötigt wird. Das ist um ein vielfaches effizienter als jeder Garbage-Collector. Und es macht den Code schöner und aussagekräftiger. Meiner Meinung nach hat C++ damit die schönste und sauberste Speicherverwaltung aller Programmiersprachen die ich kenne.

Zitat von »Jonathan_Klein«

Außerdem würde ich sie im Normalfall in einen std-Container packen, und da werden Objekte nunmal hin und her kopiert. Also nehme ich einen Container mit std::uniqu_ptr, weil ich keine Lust habe, komplexe Objekte zu kopieren.

Kopieren ist so nicht richtig. Wenn du garantierst, dass dein move-Konstruktor keine Exceptions wirft (noexcept), wird dieser auch benutzt.