#include "stdafx.h"
#include <vector>

class A{

	int &Ai;

public:

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

	A& operator=(const A& scr){
	  this->Ai=scr.Ai;
	  return *this;
	 }

	const int& GetI(){
	  return Ai;
	}

};

class B{

	public:
	std::vector<A> DATA;
	int i;

	B(){
	  DATA.push_back(A(i));
	}

	const A& GetA(){
	  return DATA[0];
	}

};

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

	B o;

	int i=o.GetA().GetI(); // <---- FEHLER

	return 0;
}

Compiler melde folgenen fehler: error C2662: 'A::GetI': this-Zeiger kann nicht von 'const A' in 'A &' konvertiert werden
1> Durch die Konvertierung gehen Qualifizierer verloren

Muss ich wohl bei GetA da das const weglassen?

Übrigens: const int& als Rückgabetyp ist wohl eher sinnlos, was soll das bringen? Ich würds so umschreiben:

int get_i() const {
    return Ai;
}

MfG SideWinder

A& operator=(const A& scr){
      this->Ai=scr.Ai;
      return *this;
     }

hab das immer noch net verstanden, hat was mit dem vector zu tun

=> Warum implementierst du eine der Drei? Warum verzichtest du auf die anderen Beiden?

MfG SideWinder

Übrigens: const int& als Rückgabetyp ist wohl eher sinnlos, was soll das bringen?

ist nicht sinnlos. ohne const könntest du das kompillieren:

my_object.get_i() = 40;

mit const beim rückgabewert führt sowas zu einem compilerfehler.

@dot: Nicht "int&" sondern "int" statt "const int&". Das liefert dann:

error C2106: '=': Linker Operand muss ein L-Wert sein

MfG SideWinder

const int get_i() const {
    return Ai;
}

das meinte ich. hab mich leider ziemlich blöd ausgedrückt^^

MfG SideWinder

(t ist ein Objekt vom Typ T, u ein Objekt vom Typ const T)
Der Standard definiert meines Wissens nicht, was genau Äquivalenz hier bedeuten soll - zweifellos soll diese Bedeutung aber in beiden Fällen gleich sein.
Ein implizit deklarierter Zuweisungsoperator kann nicht definiert werden, wenn die Klasse einen Referenzmember hat - damit würde A dann von vornherein das Assignable-Kriterium nicht erfüllen.

Da kannst du aber auch int statt const int schreiben, liefert ebenfalls einen Compilerfehler. Siehe oben.

stimmt sry, war grad ein bisschen verwirrt

Oft genug beruhen nicht-statische Referenzmember, ebenso wie konstante member, auf einem Denkfehler und sind den damit verbundenen Ärger im allgemeinen nicht wert.

Ich habe es eher öfter erlebt dass Leute eine Klasse schreiben die eigentlich noncopyable sein müsste, diese aber kopierbar machen (oder lassen, wenn der Compiler alles nötige erzeugen kann).

camper schrieb:

Oft genug beruhen nicht-statische Referenzmember, ebenso wie konstante member, auf einem Denkfehler und sind den damit verbundenen Ärger im allgemeinen nicht wert.

Ich habe es eher öfter erlebt dass Leute eine Klasse schreiben die eigentlich noncopyable sein müsste, diese aber kopierbar machen (oder lassen, wenn der Compiler alles nötige erzeugen kann).

Allerdings hat das Eine mit dem Anderen wenig zu tun. Klassen kopierbar zu machen, die es nicht sein sollten, ist zweifellos ein Fehler - andererseits sind genannte Member nicht in der Lage, Kopierbarkeit zu verhindern - folglich auch nicht das Mittel der Wahl dafür. Insofern entgeht mir, worauf du hinaus willst.

int &PropertyI(){

return iA;

}

jetzt kann ich iA lesen und iA schreiben, brauche keien getrennten Get/SEt methoden , weil es sich wie das Propertymethode in VB verhält:)

A obj;

int g= obj.PropertyI();

obj.PropertyI(); = 7;

Mann lernt nie aus, dachte sowas gwürd nich gehen;)