Gruß

Referencer

Für den Programmierer ist er sicherer, da eine Referenz nicht 0 sein kann.

Das ist schwachsinn. In vielen Fällen kann es sinnvoll und erwünscht sein, einen 0-Wert zu haben. Und Dangling references verweisen nicht mehr auf Objekte.

Ich würde sagen wann Übergabe als Referenz besser ist als Wertübergabe kann man nicht so einfach sagen. Die Faustregel wäre primitive Typen (int, double, ...) als Wert zu übergeben und komplexere Typen als Referenz. Allerdings würde ich sagen das hängt auch davon ab wie diese Objekte dann verwendet werden. Wenn du ein etwas komplexeres Objekt hast, das aber sehr sehr oft referenziert wird, könnte es vielleicht passieren, dass der Overhead durch die zusätzliche Indirektion größer wird als der Overhead durch einmaliges Kopieren. Absolute Gewissheit bekommt man nur indem man den konkreten Fall profiled.

Vielleicht ganz interessant: http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/

struct Foo
{
   Bar& b;
};

wie groß ist sizeof(Foo)?

Und rund wird es, wenn man noch dazusagt, daß Referenzen durchaus anders implementiert sein könnten. Dann erwartet man zwar, daß ein Foo 4/8 Bytes groß ist, weiß aber auch, daß es dafür keine Zusage gibt.

Warum gibts eigentlich keine void&'s?

Wie soll man diese initialisieren?

Und was willst du mit dieser Reference to void dann anstellen?

Ganz normal wieder hochcasten.

Also verwenden wie einen void*, aber mit dem Unterschied, daß eine void& nicht *nullptr referenzieren darf. Zum Beispiel für Datenstrukturen, die nur sehr wenig über die verwalteten Daten wissen müsen, um template-Instanzen klein zu halten und gemeinsamen Code der allgemeinen Verwaltung zu benutzen.

template<typename T>
class Datenstruktur
{
   AllgDatenstruktur data;
   T& peek()
   {
      void& v=data.peek();
      return static_cast<T&>(v);
   }

Mit void* muß der Compiler davon ausgehen, daß data.peek() einen nullptr liefern könnte. Da könnte ihn je nach Maschine dazu zwingen, anzunehmen, eine NullPointerException könne fliegen oder ihn wenigstens von mancher Optimierung abhalten. Und der Programmierer weiß auch, daß peek() immer ein Objekt zurückliefert.

Hi, wie groß ist eigentlich eine Referenz

3.82m

...

Aber dazu ist doch schon der Templateparameter da.

template<typename T>
class Datenstruktur
{
   AllgDatenstruktur data;
   T& peek()
   {
      T& v = static_cast<T&>(data.peek()); // Es ist ja schon vorausgesetzt, dass peek() in T& castbar ist.
      return v; // Oder v gleich weglassen.
   }

volkard schrieb:

...

Aber dazu ist doch schon der Templateparameter da.

template<typename T>
class Datenstruktur
{
   AllgDatenstruktur data;
   T& peek()
   {
      T& v = static_cast<T&>(data.peek()); // Es ist ja schon vorausgesetzt, dass peek() in T& castbar ist.
      return v; // Oder v gleich weglassen.
   }

Ja, aber data.peek() muß eine void& zurückgeben.

Ich sehe keinen Gewinn darin, zu leugnen, daß Referenzen verkappte Zeiger sind.
Viele Fragestellungen kann man mit dieser Sichtweise sinnvoll beantworten

Aber viele entstehen auch erst durch diese Sichtweise. Adressierbarkeit, Wertsemantik, Speicherung in Arrays, Grössenermittlung, Veränderbarkeit... Alles Themen, die aufkommen, weil man versucht, Referenzen wie Objekte anzusehen. Die Indirektion ist natürlich wie bei Zeigern vorhanden, aber grundsätzlich kommt die abstrakte Vorstellung eines Alias recht nahe hin.

Aber void& fände ich schon etwas befremdlich. Schon mit void* kann man fast nichts anstellen, aber mit void& ? Da ist sogar der ganz normale Zugriff ein Fehler.

PtrPtr schrieb:

Für den Programmierer ist er sicherer, da eine Referenz nicht 0 sein kann.

Das ist schwachsinn. In vielen Fällen kann es sinnvoll und erwünscht sein, einen 0-Wert zu haben. Und Dangling references verweisen nicht mehr auf Objekte.

Dann könnte man sich die Referenz auch sparen und nur mit Pointer arbeiten.

314159265358979 schrieb:

PtrPtr schrieb:

Für den Programmierer ist er sicherer, da eine Referenz nicht 0 sein kann.

Das ist schwachsinn. In vielen Fällen kann es sinnvoll und erwünscht sein, einen 0-Wert zu haben. Und Dangling references verweisen nicht mehr auf Objekte.

Dann könnte man sich die Referenz auch sparen und nur mit Pointer arbeiten.

Was meinst du, warum es immer noch Pointer in C++ gibt? Es gibt noch genug Situationen, in denen eine Referenz nicht ausreicht.

Dann könnte man sich die Referenz auch sparen und nur mit Pointer arbeiten.

Kann man in den meisten Fällen ja auch. Für Operatoren und den Kopierkonstruktor mußten sie eingeführt werden. Ob man dann im Weiteren sie so selten wie möglich oder so oft wie möglich verwendet, ist eine ganz andere Frage. Beide Wege wären mir zu extrem.

CStoll, du hast PtrPtr wahrscheinlich falsch verstanden. Er sagt ja nur, dass Referenzen in gewissen Fällen sicherer sind als Zeiger. Dass Pi dies als Schwachsinn bezeichnet mit der Begründung, man brauche die Sicherheit manchmal nicht, ist wirklich etwas fragwürdig.

Schon möglich. Im Zweifelsfall gebe ich die Frage halt direkt an Pi weiter

PS: Das Beispiel für die Einführung von void-Referenzen halte ich für reichlich sinnlos. Wer immer die Daten dort bereitstellt, muß schließlich wissen, wie sie aufgebaut sind, also kann er auch gleich den richtigen Datentyp zurückgeben. (btw, selbst void-Zeiger sind im Zusammenhang mit C++ Objekten imho schon problematisch)

Wer immer die Daten dort bereitstellt, muß schließlich wissen, wie sie aufgebaut sind,

Ich gebe ja zu, daß dieses Muster nicht mehr modern ist. Aber mehr als sizeof(T) bzw falls verfügbar sizeof(T) und alignof(T) ist gelegentlich gar nicht notwendig für den Container. Das ist nur das Schubsen der Verzeigerung oder allgemein von so Verwaltungsdingen in eine tiefere Schicht, wie neulich beim base_node eines doppelt verketten Rings passiert.

Dass Pi dies als Schwachsinn bezeichnet mit der Begründung, man brauche die Sicherheit manchmal nicht, ist wirklich etwas fragwürdig.

Ich wollte damit sagen, dass Referenzen nicht immer einem Zeiger vorgezogen werden sollen. Aber offenbar hab auch ich das falsch verstanden.