Frage zum verhalten Referenzvarablen?

BorisDieKlinge

Im folgendem Code wurde mit Referenzvariablen gearbeitet:

int k; //GLOBAL

class A{
public:
	int &iA;

	A(int &i): iA(i){}

	int &ChangeI(){
	 return iA;
	}
	int &ChangeK(){
	  return k;
	}

};

class B{

public:
	int &iB;

	B(int &i) : iB(i){}

	int &ChangeI(){
	 return iB;
	}
	int &ChangeK(){
		return k;
	}

};

int _tmain(int argc, _TCHAR* argv[]){

int i=6;
k=7;

B b(i);
A a(i);

	return 0;
}

Das verhalten von i und k über die funktionen "changeI/changek ist aqvivalent, oder gibts es trozdem unterschiede?

EDIT: Wann ist es allgemein besser, wenn ich hier statt mit referenzen bei iA /IB mit pointer arbeiten würde?

CStoll

Erstens: Wo in deinem Code wird denn mit den Change-Methoden gearbeitet?
(btw, bei einer Funktion ChangeI() erwarte ich, daß sie irgendwas verändert - und nicht nur einen Wert zurückgibt)

Zweitens: Der Vorteil von Referenzen ist hier, daß jede davon auf eine eigene Variable verweisen kann (außerdem kannst du auch lokale Variablen über Referenzen erreichen - zumindest solange sie diese Referenz überleben):

int i;
A a1(i),a2(k);

Drittens: Mit Zeigern sollte man nur arbeiten, wenn Referenzen nicht geeignet sind - d.h. wenn NULL-Werte möglich sind oder der Verweis zur Laufzeit umgehängt werden könnte.

BorisDieKlinge

Bspw:

b.ChangeI() = 6;
int res= b.ChangeI();

asc

BorisDieKlinge schrieb:

Bspw:

b.ChangeI() = 6;
int res= b.ChangeI();

Da würde ich eher über Operatorüberladung nachdenken. Es ist IMHO auf jeden Fall ein sehr ungewöhnlicher Stil.

cu André

BorisDieKlinge

jepp.. hat mich überrascht das die geht... ähnlich der Property eigenschaft in VB

Airdamn

Nicht wirklich.
Du hast hier direkt Zugriff auf ein Member und kannst ihn nach belieben verändern. Bei Properties sieht es nur so aus, als ob Du ein Member direkt änderst. In Wirklichkeit ist da aber eine interne setter-methode zugange.

In Deinem Beispiel geht die Datenkapselung flöten...

CStoll

BorisDieKlinge schrieb:

ähnlich der Property eigenschaft in VB

Nicht wirklich - bei einer Property kannst du kontrollieren, was mit deinen Membern passiert. Bei dem Ansatz gibst du die Zugangskontrolle ab (wie ich in einem anderen Thread schon schrieb, könntest du iA gleich public setzen und hast den selben Effekt).

*D*Evil

template<typename T>
class foo
{
    T& m_data;

public:
    A(T& ref) : m_data(ref) {}

// Set/Get
public:
    T const& data() const { return m_data; }
    void data(T& ref) { m_data = ref; }

// operator T()
public:
    T& operator T() { return m_data; }
};

... so kann man es machen ... sollte man aber auch nicht(2. Methode) ...