der C++ Standard sagt laut Wikipedia folgendes: "There shall be no references to references, no arrays of references, and no pointers to references."

Was ist mit "references to references" gemeint?

Wenn ich z.B. folgende Situation habe:

class A { };

void bar(const A& a)
{
  // Process a
}

void foo(const A& a)
{
  bar(a);
}

int main()
{
  A a;
  foo(a);
}

Ist das a in bar() dann eine Referenz auf eine Referenz und deswegen nicht legal?

int i = 0;
int & r = i; // ok
int & & rr = r; // nicht ok

int i = 0;
int & r = i; // ok
int & & rr = r; // nicht ok

int & r2 = r; // auch OK, r bezieht sich ja auf i
              // und r2 ist auch nur eine Referenz-auf-int

Man kann sich Referenzen als automatisch dereferenzierende Zeiger vorstellen, bei denen man beim Initialisieren auch nicht den Adress-Operator benötigt:

int   i = 0;

int & r = i;
cout << r;

int * p = &i;
cout << *p;

Dementsprechend ist

int & r2 = r;
cout << r2;

vergleichbar mit

int * p2 = &r; // Beachte: &r == &i
cout << *p2;

kk

krümelkacker schrieb:

Dementsprechend ist

int & r2 = r;
cout << r2;

vergleichbar mit

int * p2 = &r; // Beachte: &r == &i
cout << *p2;

Aber wäre p2 dann nicht ein Zeiger auf eine Referenz? Oder was ist wiederrum mit "no pointers to references" gemeint?

Gruß,
Referenz

Hallo.
Hab auch kurz ne Frage zu Referenzen:
Wie kann ich wissen ob das Objekt hinter der Referenz noch lebt? Was passiert wenn das Objekt nicht mehr gültig ist? Welche Exception wird da geworfen?
Danke
lg

Absturz oder sowas passiert dann.
Der Klassiker ist

int& foo()
{
   int lokal=5;
   return lokal;
}

Wie kann ich wissen ob das Objekt hinter der Referenz noch lebt?

Indem du korrekten Code schreibst, dann ist das nämlich immer der Fall.

Wie kann ich wissen ob das Objekt hinter der Referenz noch lebt?

Indem du korrekten Code schreibst, dann ist das nämlich immer der Fall.

In der Theorie ja. Aber warum dann groß Referenzen nehmen? Pointer kann ich auf NULL testen, Referenzen nicht.
Beispiel:

class foo
{
  OtherClass* m_a;

  foo() : m_a(new OtherClass)
  {}

  OtherClass& getA() { return *m_a; }
}

Wenn das Objekt m_a gelöscht wurde, crasht mir das hier quasi einfach weg? Gibts keine NullReference wie in Java?
lg

In der Theorie ja. Aber warum dann groß Referenzen nehmen? Pointer kann ich auf NULL testen, Referenzen nicht.

Es werden ja auch viel zu viele Referenzen statt Pointern genommen. Referenzen sind nötig, um Operatorüberladung und Kopierkostruktoren hinzukriegen.

Gute Referenzen schrieb:

Wenn das Objekt m_a gelöscht wurde, crasht mir das hier quasi einfach weg? Gibts keine NullReference wie in Java?

Nee, das ist verboten. Es klappt zwar, aber offiziell klappt es nicht.
Wenn man NULL auch drin braucht, MUSS man Zeiger nehmen.

Gute Referenzen schrieb:

In der Theorie ja. Aber warum dann groß Referenzen nehmen? Pointer kann ich auf NULL testen, Referenzen nicht.

Es werden ja auch viel zu viele Referenzen statt Pointern genommen. Referenzen sind nötig, um Operatorüberladung und Kopierkostruktoren hinzukriegen.

Was ist an der Referenz hier schlecht/zu viel?

void foo(Class const& object)

Damit muss doch nur der Aufrufer sicher stellen, dass er mir ein gültiges Objekt gibt und ich muss nicht in der Funktion (nochmal) auf NULL prüfen.

krümelkacker schrieb:

Dementsprechend ist

int & r2 = r;
cout << r2;

vergleichbar mit

int * p2 = &r; // Beachte: &r == &i
cout << *p2;

Aber wäre p2 dann nicht ein Zeiger auf eine Referenz?

Nein. Wie gesagt, eine Referenz ist wie ein sich automatisch dereferenzierender Zeiger. Daher entspricht der Ausdruck &referenz eher &*zeiger , welches die Adresse des referenzierten Objekts liefert.

Aber warum dann groß Referenzen nehmen? Pointer kann ich auf NULL testen, Referenzen nicht.

Referenzen sind praktisch für "pass by reference". Man kann eine Referenz-auf-const verwenden, wenn die Funktion das Objekt nicht ändern muss. Damit spart man das Kopieren des Objekts; denn mit pass-by-value werden die Objekte kopiert:

void dings(string s) { cout << s; }
void bums(string const& cref) { cout << cref; }

int main()
{
  string hw = "hello world!";
  dings(hw); // #1
  bums(hw);  // #2
}

Bei #1 muss für die Funktion eine lokale Kopie des string-Objekts erzeugt werden. Wenn dings ihr s verändert, hat das keinen Einfluss auf das hw Objekt. Das Kopieren kann aber u.U. Zeit/Speicher kosten. dings muss s nicht verändern. Bei #2 wird nur eine Referenz auf das Objekt übergeben. Da das referenzierte Objekt auch const-qualifiziert ist, kann die Funktion bums nicht versehentlich das hw-Objekt verändern. Wir haben uns hier eine unnötige Kopie gespart.

Nicht-Const-Referenzen können auch praktisch sein:

void swap(int& a, int& b)
{
  int c = a; a = b; b = c;
}

int foo()
{
  int a = 23;
  int b = 42;
  swap(a,b);
  cout << a << ' ' << b;  // gibt 42 23 aus
}

Klar, mit Zeigern geht das auch:

void swap(int* a, int* b)
{
  if (!a || !b) throw std::invalid_argument("ich will keine Nullzeiger!")
  int c = *a; *a = *b; *b = c;
}

int foo()
{
  int a = 23;
  int b = 42;
  swap(&a,&b);
  cout << a << ' ' << b;  // gibt 42 23 aus
}

In anderen Fällen sind sie aber notwendig:

class meine_array_abstraktion
{
  int* start;
  int* ende;
public:
  explicit meine_array_abstraktion(std::size_t anzahl_elemente = 0);
  meine_array_abstraktion(meine_array_abstraktion const&); // #1
  meine_array_abstraktion& operator=(meine_array_abstraktion const&); // #2
  ~meine_array_abstraktion();
  int      & operator[] (std::size_t index)       {return start[index]} // #3
  int const& operator[] (std::size_t index) const {return start[index]}
  std::size_t size() const {return ende-start;}
};

#1: Der Kopierkonstruktor muss eine Referenz entgegennehmen.
#2: Der Zuweisungsoperator sollte eine Referenz auf *this zurückgeben
#3: Diese Funktion, welche eine Referenz zurückgibt, erlaubt dem Nutzer das Verändern eines Elements mit der natürlichen Syntax:

meine_array_abstraktion maa = ...;
  maa[0] = 23;
  maa[1] = 42;
  maa[2] = 1729;

Referenzen, nachdem sie initialisiert wurden, sind unveränderlich -- also, man kann sie nicht dazu bringen, nachträglich etwas anderes zu referenzieren. Durch diese drei Zuweisungen werden die referenzierten Objekte verändert. Das ergibt sich auch wieder aus dem "initialisierte Referenzen verhalten sich wie sich selbst dereferenzierende Zeiger"-Gedanken.

Damit muss doch nur der Aufrufer sicher stellen, dass er mir ein gültiges Objekt gibt und ich muss nicht in der Funktion (nochmal) auf NULL prüfen.

Muß ich auch so nicht. Testet strcpy gegen NULL? Es ist doch offensichtlicher Schwachsinn, NULL zu übergeben. Auch beim folgenden swap-Beispiel. Dagegen muß keiner Testen. Und vor allem nicht mit throw den Fehler anzeigen.
Wer das macht, der frißt auch kleine Kinder und sagt if(&ref!=NULL). krümelkacker hat das jetzt nur mal zur Demo gemacht.

DeepPurple schrieb:

Damit muss doch nur der Aufrufer sicher stellen, dass er mir ein gültiges Objekt gibt und ich muss nicht in der Funktion (nochmal) auf NULL prüfen.

Muß ich auch so nicht. Testet strcpy gegen NULL? Es ist doch offensichtlicher Schwachsinn, NULL zu übergeben. Auch beim folgenden swap-Beispiel. Dagegen muß keiner Testen. Und vor allem nicht mit throw den Fehler anzeigen.
Wer das macht, der frißt auch kleine Kinder und sagt if(&ref!=NULL). krümelkacker hat das jetzt nur mal zur Demo gemacht.

Und wie beantwortet das jetzt meine Frage?

Was ist an der Referenz hier schlecht/zu viel?

void foo(Class const& object)

Oder, was ist hier besser?

void foo(Class const* object)

• Manche Leute verwenden Const-Referenzen nur zur Beschleunigung, die Semantik wäre gleich wie bei einer Kopie. Sie würden aber intern keine Zeiger darauf speichern. Wenn das Objekt verändert wird, übergeben sie Zeiger. Referenzen auf nicht-konstante Objekte haben gar keine Verwendung.
• Andere benutzen in Parameterlisten Zeiger, wenn NULL ein gültiger Wert ist, und sonst Referenzen. Ich handhabe das z.B. so.

Das kommt auf deinen Stil an. Im Wesentlichen gibt es zwei Fraktionen:

• Manche Leute verwenden Const-Referenzen nur zur Beschleunigung, die Semantik wäre gleich wie bei einer Kopie. Sie würden aber intern keine Zeiger darauf speichern. Wenn das Objekt verändert wird, übergeben sie Zeiger. Referenzen auf nicht-konstante Objekte haben gar keine Verwendung.
• Andere benutzen in Parameterlisten Zeiger, wenn NULL ein gültiger Wert ist, und sonst Referenzen. Ich handhabe das z.B. so.

Das schließt sich doch gar nicht aus. Oder verstehe ich da etwas falsch?

Das schließt sich doch gar nicht aus.

Doch. Leider kann man nicht die Vorteile beider Varianten benutzen. Entweder drückt ein Zeiger in der Schnittstelle aus, dass das Objekt verändert wird oder dessen Adresse gespeichert wird (und verunmöglicht gerechtfertigterweise temporäre Objekte), oder er impliziert, dass NULL übergeben werden darf.

// ---- Fraktion 1 ---------------------------------------------
void Fn(const T& ref)
{
    // Speichere nirgends die Adresse von ref
}

void Fn(T* ptr)
{
    // Verändere *ptr oder speichere dessen Adresse
    // Es ist für den Aufrufer unklar, ob NULL erlaubt ist
}

void Fn(const T* ptr)
{
    // Speichere ptr
    // Es ist für den Aufrufer unklar, ob NULL erlaubt ist
}

// ---- Fraktion 2 ---------------------------------------------
void Fn(T& ref)
{
    // Möglicherweise Speicherung von &ref
    // ref kann verändert werden
}

void Fn(const T& ref)
{
    // Möglicherweise Speicherung von &ref
}

void Fn(T* ptr)
{
    // NULL ist sicher ein erlaubter Wert
    // Falls gültiger Zeiger, verändere *ptr oder speichere ptr
}

void Fn(const T* ptr)
{
    // NULL ist sicher ein erlaubter Wert
    // Speichere ptr
}