Zeiger als Parameter... Verständnissproblem

FrankTheFox

Hallo,

wennn ich Zeigeer programmiere dann ist...

int x;  //variable x!
 int *ptr = NULL ; //zeiger auf einen int.

also x hat ja eine Adresse und einen Wert

x=3;

ich hslt nur den Bezeichner x zur Verfügung um den Wert zu ändern, aber mit einem Zeiger geht das auch indirekt

ptr = &x; // jetzt hat ptr die Adresse

also ein Zeiger speichert keinen Wert sondern Adressen!!!!
dann kann aso von x der Wert geändert werden...

*ptr= 19;

Ok, nun die Funktion (ein Beispiel)

swap(int* a, int* b);

Aufruf:

int x,y;
swap(&x, &y);

Würde man keine Zeiger übergeben, dann würden von den originalen Kopien erstellt und mit denen gearbeitet.

Originale : x,y
Kopien ;a,b

mit den Zeigern werden zwar immer noch Kopien angelegt, aber die beinhalten keine Werte, sondern Adressen!! Somit werden also die Originale verändert.

Ich stelle mir das so vor: int a = &x;* und int b = &y;*

jetzt kann ich aber auch sowas machen....

swap(int &a, int &b);

//Aufruf

int x,y;
swap (x,y);

Wie kann ich mir das den vorstellen????

x = &a; ?????

Kann mich da jemand auf den Pfad der Erleuchtung bringen?

Gruß
Franky

XSpille

Kuck dir mal das Thema Referenzen an.

Das &-Zeichen in der Funktion steht nämlich für eine Referenz.
Referenzen sind quasi nachdem sie einmal initialisiert wurden unveränderbare
Zeiger, die nicht 0 werden können. Deswegen brauch man sie nicht
explizit dereferenzieren, wie du im folgenden Beispiel siehst:

#include<iostream>

int main() {
        int i=2;
        int& j = i;
        j = 3;
        std::cout << i << std::endl;
        return 0;
}

3

Du greifst also auf das Objekt zu ohne den 'Zeiger' dereferenzieren zu brauchen.

Gruß,
XSpille

FrankTheFox

Ok,

danke für die Antwort. Wenn ich das richtig sehe, dann muß die Referenz schon während der Dekalration an die Variable gebunden sein...

XSpille schrieb:

int& j = i;

Sowas wie bei gewöhnlichen Zeigern

int i;
int j;
 &j = i; //Murks

geht nicht. Ist die Referenz einmal gebunden, kann sie auch nicht mehr getrennt werden, also umgehängt.

Deswegen ist also auch

int const&

äquivalent zu

const int&

also kann ich mir das dann so vorstellen:

int &a = x;
Gruß
Franky

Nexus

FrankTheFox schrieb:

danke für die Antwort. Wenn ich das richtig sehe, dann muß die Referenz schon während der Dekalration an die Variable gebunden sein...

Nein, aber bei der Initialisierung. Ist zwar manchmal gleichzeitig, aber nicht immer. Z.B. In Klassen oder bei der Benutzung von extern .

FrankTheFox schrieb:

Ist die Referenz einmal gebunden, kann sie auch nicht mehr getrennt werden, also umgehängt.

Korrekt.

FrankTheFox schrieb:

Deswegen ist also auch
int const&
äquivalent zu
const int&

Nein, nicht deswegen. Das hat damit nichts zu tun. Die Äquivalenz besteht aus dem gleichen Grund wie hier:

const int
int const

FrankTheFox schrieb:

also kann ich mir das dann so vorstellen:
int &a = x;

Ich weiss jetzt nicht, was du dir hier vorstellst, aber so kannst du es schreiben, ja. Auch wenn ich persönlich das & beim Typ und nicht bei der Variable hinsetze.

FrankTheFox

Hallo,

habe derzeit noch mal die Anregungen durchgearbeitet.

Nexus schrieb:

FrankTheFox schrieb:

danke für die Antwort. Wenn ich das richtig sehe, dann muß die Referenz schon während der Dekalration an die Variable gebunden sein...

Nein, aber bei der Initialisierung. Ist zwar manchmal gleichzeitig, aber nicht immer. Z.B. In Klassen oder bei der Benutzung von extern .

Ja, wenn ich sowas mache

int y;
 int &x = y;  //1.)

dann muß ich diese Zeile so umsetzten, aber z.B. in Klassen

geht das auch so...

class MyClass {

 MyReference& m_reference; //2.)

public:

 MyClass( MyReference& reference ) :
  m_reference( reference ) {}    

};

2.) Hier erfolgt erst eine Deklaration, dann im Konstruktor eine Initialisation.
1.) Hier deklaration und dann sofort init (ausser mit extern) läßt sich das nicht trennen. In einer Klasse läßt sich das so auch in zwei Schrtten machen

FrankTheFox schrieb:

Deswegen ist also auch
int const&
äquivalent zu
const int&

Nein, nicht deswegen. Das hat damit nichts zu tun. Die Äquivalenz besteht aus dem gleichen Grund wie hier:

const int
int const

Ja, stimmt. Da habe ich nicht nachgedacht...

Ich denke so ist es jetzt klarer! Danke!

Gruß
Franky