Unterschied Referenz, Zeiger

Hallo,

Referenz: es wird einfach die Variable selbst verwendet
Zeiger: Es wird Adresse in Zeiger kopiert, dann wird darauf per Zeiger zugegriffen und das Orginal manipuliert.

So hab ich das im Vorstellungsgespräch gesagt und es hat nicht ganz gestimmt bzw was gefehlt.

#include <cassert>

int main()
{
//hört sich sehr schwammig an - als wenn du keine Ahnung hättest

//variable
int a = 10;

//Zeiger auf a
int* pa = &a;
assert(pa == &a);
assert(*pa == a);

//Referen auf a
//Unterschied zu Zeiger: Referenz hat die gleiche Semantik
//wie ein Zeiger kann aber nicht nachträglich gaendert
//werden und darf auch nicht 0 sein
int& ra = a;
assert(ra == a);
assert(&ra == pa);

//also ist ein referenz wie ein const-ptr
//nur mit der Nicht-0 Einschränkung
int* const pca = &a;
/pca = 0 oder andere wert nicht erlaubt
assert(pca == &a);
assert(*pca == a);

return 0;
}

Man kann einen Zeiger auf etwas anderes zeigen lassen, eine Referenz zeigt immer auf dasselbe Objekt. Außerdem kann ein Zeiger auf 'nichts' zeigen, bzw. ein nullptr sein, aber eine Referenz kann dies nicht.

lol mich würd mal intressieren wie Referenz intern behandelt wird.
Bestimmt ist es auch ein Zeiger intern.

funk(int& var)
{

}

CPlusPlusNewbie schrieb:

lol mich würd mal intressieren wie Referenz intern behandelt wird.
Bestimmt ist es auch ein Zeiger intern.

funk(int& var)
{

}

Ja, in diesem Fall schon.

void test()
{
int x = 1;
int& xx = x;
}

In diesem Fall nicht.

SeppJ

CPlusPlusNewbie schrieb:

lol mich würd mal intressieren wie Referenz intern behandelt wird.
Bestimmt ist es auch ein Zeiger intern.

Kann sein, muss aber nicht. Genausowenig muss ein Zeiger intern nicht unbedingt ein Zeiger sein. Das übersetzte Programm muss sich bloß so verhalten, als ob es zu deinem Code passt. Das beobachtbare Verhalten schließt aber Details der Implementierung größtenteils aus. Gerade bei Referenzen, bei denen man nicht einmal theoretisch die Adresse der Referenz erhalten kann, sind möglichen Optimierungen Tür und Tor geöffnet.

Aber wenn eine Referenz tatsächlich eine Identität im übersetzten Programm hat, dass wird diese einem Zeiger ähneln, ja.

Also bislang war ich ja kein Fan von Referenz, sondern eher von Zeigern.

Aber Referenz ist doch viel besser als Zeiger ?? Referenz verwend ich einfach so wie die normale Variable und muss mich nicht mit Zeiger rumschlagen wenn ich es nicht brauche.

Nathan

Newbie68697 schrieb:

Aber Referenz ist doch viel besser als Zeiger ?? Referenz verwend ich einfach so wie die normale Variable und muss mich nicht mit Zeiger rumschlagen wenn ich es nicht brauche.

Referenzen können sich aber nicht ändern.
Das führt dann dazu, dass Klassen, die Referenzen als Member haben, keinen idR Zuweisungsoperator vernünftig implementieren können.

JulianH

hardware schrieb:

Man kann einen Zeiger auf etwas anderes zeigen lassen, eine Referenz zeigt immer auf dasselbe Objekt. Außerdem kann ein Zeiger auf 'nichts' zeigen, bzw. ein nullptr sein, aber eine Referenz kann dies nicht.

void func(int& ref) {}
int main()
{
    int* x = 0;
    func(*x); // läuft
}

Referenzen sind das Selbe wie Pointer, nur dass der Kompiler keinen Pointer Syntax verlangt.

eine Referenz kann nicht 0 sein, muss auf etwas vorhandenes initalisiert sein und darf nachträglich nicht geändert werden - das sind ganz ordentliche Unterschiede zu Zeigern

Referenzen helfen dabei den Code sauberer zu schreiben - siehe z.B. const-correct
der Funktionlitätsvergleich ist hier fehl am Platz weil Referenzen eher ein besseres Design-Element als Pointer sind - denn es ist teilweise schön zu wissen das etwas für immer seinen Zustand hält und nicht ständig mit if/else oder sonstwie hingebogen werden kann

Columbo

Nathan schrieb:

Newbie68697 schrieb:

Aber Referenz ist doch viel besser als Zeiger ?? Referenz verwend ich einfach so wie die normale Variable und muss mich nicht mit Zeiger rumschlagen wenn ich es nicht brauche.

Referenzen können sich aber nicht ändern.
Das führt dann dazu, dass Klassen, die Referenzen als Member haben, keinen idR Zuweisungsoperator vernünftig implementieren können.

Doch, können sie - ich nenne folgendes jedenfalls vernünftig:

struct A {
	int& ref;
	std::string str;

	A& operator=(A const& a) {
		if (this != &a) {
			this->~A(); // Hier erwünscht, nicht nötig
			new (this) A(a);
		}
		return *this;
	}
};

JulianH

Gast3 schrieb:

eine Referenz kann nicht 0 sein, muss auf etwas vorhandenes initalisiert sein und darf nachträglich nicht geändert werden - das sind ganz ordentliche Unterschiede zu Zeigern

Referenzen helfen dabei den Code sauberer zu schreiben - siehe z.B. const-correct
der Funktionlitätsvergleich ist hier fehl am Platz weil Referenzen eher ein besseres Design-Element als Pointer sind - denn es ist teilweise schön zu wissen das etwas für immer seinen Zustand hält und nicht ständig mit if/else oder sonstwie hingebogen werden kann

Das sind übliche Konventionen - das ist richtig.

Mr.Long schrieb:

Gast3 schrieb:

eine Referenz kann nicht 0 sein, muss auf etwas vorhandenes initalisiert sein und darf nachträglich nicht geändert werden - das sind ganz ordentliche Unterschiede zu Zeigern

Referenzen helfen dabei den Code sauberer zu schreiben - siehe z.B. const-correct
der Funktionlitätsvergleich ist hier fehl am Platz weil Referenzen eher ein besseres Design-Element als Pointer sind - denn es ist teilweise schön zu wissen das etwas für immer seinen Zustand hält und nicht ständig mit if/else oder sonstwie hingebogen werden kann

Das sind übliche Konventionen - das ist richtig.

Was genau bezeichnest du hier als Konvention?

JulianH

Dass man Referenzen dort benutzen sollte, wo sie nie 0 sein sollten.

Ruvi

Mr.Long schrieb:

Dass man Referenzen dort benutzen sollte, wo sie nie 0 sein sollten.

Ich persoenlich faende "kann" schoener als "sollte".

Im Zuge der Lesbarkeit des Codes wuerde ich persoenlich Pointer Referenzen vorziehen, wenn es sich e.g. um Member von Klassen handelt.

Nichts sagt so schoen ich "owne" die Resource nicht, wie ein nativer Pointer.

hustbaer

@Arcoth
Du nennst Code vernünftig der nichtmal basic exception safety bietet?

Columbo

hustbaer schrieb:

@Arcoth
Du nennst Code vernünftig der nichtmal basic exception safety bietet?

Ich dachte der Sarkasmus hätte nicht angedeutet werden müssen.