Größe von Referenzen?

[EOutOfResources]

Das Konzept hinter Referenzen ist ja, dass sie nach der Initialisierung genau gleich wie das eigentlich Objekt zu benutzen sind, oder? Und wenn ich nun etwas mit answer machen will, müsste ich es zuerst casten. Und das würde dieses Konzept ausser Kraft treten lassen.

[volkard]

dot schrieb:

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.

[314159265358979]

---

[Nachmesser]

Referencer schrieb:

Hi, wie groß ist eigentlich eine Referenz

3.82m

[SeppJ]

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.
   }

[volkard]

SeppJ schrieb:

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.

[Nexus]

volkard schrieb:

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]

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.

[CStoll]

PtrPtr schrieb:

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.

[volkard]

PtrPtr schrieb:

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.

[Nexus]

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.

[CStoll]

Nexus schrieb:

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)

[volkard]

CStoll schrieb:

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.

[314159265358979]

Nexus schrieb:

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.