Also folgende Klassen (nur auf das wesentliche beschränkt) und Code:

// a.h
class A {
public:
const B &operator[](int index) const;

private:
B &operator[](int index);
};

// b.h
class B {
public:
  void foo() const;
};

//main.cpp
int main()
{
  A a;
  a[0].foo(); // error C2248: "A::operator []": Kein Zugriff auf private Member, dessen Deklaration in der A-Klasse erfolgte.
}

Also eine Methodensignatur setzt sich aus dem Namen, Parametern und dem const-modifier zusammen. So gesehen sind die []-Operator-Methoden überschrieben, aber die private Variant verdeckt die public Variante nicht. Wieso motzt mich dann der Compiler an (wenn ich nochdazu das B-Objekt nur const brauche), wenn ich auf die public Variante zugreifen will. Kommentiere ich die private-Variante aus kommt kein Fehler mehr. Auch wenn ich mein a (const A&) caste funktionierts, aber wieso checkt der Compiler es so nicht? Jemand nen Tipp? Ist nicht essentiell, aber mich interessiert einfach wie manchmal der Compiler tickt.

gruß Philipp

Haste mal

[s]
//main.cpp 
int main() 
{ 
  A const a; 
  a[0].foo(); // error C2248: "A::operator []": Kein Zugriff auf private Member, dessen Deklaration in der A-Klasse erfolgte. [/s]
}

Versucht?

Ich würd sagen der msvc sucht die passende Funktion, die ist bei dir private.

Gruss

Haste mal

//main.cpp 
int main() 
{ 
  A const a; 
  a[0].foo(); // error C2248: "A::operator []": Kein Zugriff auf private Member, dessen Deklaration in der A-Klasse erfolgte. 
}

Versucht?

Ich würd sagen der msvc sucht die passende Funktion, die ist bei dir private.

Gruss

So würde es auch gehen, aber ich will das Objekt ja auch noch davor verändern. In meinen Augen ist hier nichts ambiguous, und es besteht eigentlich keinen Grund vom Compiler zu meckern. Vielleicht ist ja der gcc nicht so schwerfällig.

Was ich aber auch interessant finde ist, dass der Compiler die nicht const-Version stets bevorzugt.

gruß Philipp

Dein A Objekt ist nicht const, hat aber nur einen public operator [], der const ist. Der non const operator [] ist nicht zugänglich, genau das sagt dir auch der Compiler.

Es gibt aber keinen Grund, wieso der Code nicht ausführbar wäre, denn ich rufe die private Variante ja auch nicht auf!

Nochmal: Der Compiler darf die const Variante nicht aufrufen, weil das Objekt nicht const ist.

Wieso darf er die const-Variante dann aufrufen, wenn es nur diese gibt (wenn man die private non-const-Variante auskommentiert)?

Ich würde von der Logik her auch erwarten, dass der Compiler die const-Funktion nimmt, wenn die non-const zwar verfügbar, aber private is, da er es ja auch macht, wenn sie gar net da is.

Aber wenn der Standard was anderes sagt, müssen sich die Compiler natürlich dran halten, das ist wieder ein andere Paar Schuhe.

Nochmal: Der Compiler darf die const Variante nicht aufrufen, weil das Objekt nicht const ist. Und die non-const Variante ist private, also kann er die nicht aufrufen. Das ist nicht ambiguous oder sonstwas, sondern einfach nicht möglich. Der Compiler tut genau, was er laut C++ Standard tun soll.

Der Compiler darf sehrwohl die const Variante aufrufen! Folgender Code zeigt genau die Dummheit:

class A
{
public:
	void foo() const {}
	void bar() const {}
private:
	void bar(){}
};

int main()
{
	A a;
	a.foo(); // const Aufruf funktioniert
	a.bar(); // const Aufruf scheitert
}

Und der Aufruf scheitert nur, weil es eine private Methode gibt, die besser passen würde. Dümmlichst!

EDIT: Das Verhalten ist allerdings genau was der C++ Standard vorsieht. Die Überprüfung, ob der ausgewählte Member accessible ist, wird erst nach der Overload Resolution durchgeführt.

Stimmt, sorry, da war ich tatsächlich grad ziemlich verwirrt...

Ja und wenn man ihn ausdrücklich bittet funktionierts dann doch :

((const A&)a).bar(); // const Aufruf funktioniert auf einmal doch

EDIT: Das Verhalten ist allerdings genau was der C++ Standard vorsieht. Die Überprüfung, ob der ausgewählte Member accessible ist, wird erst nach der Overload Resolution durchgeführt.

Diese bessere Erklärung hatte mir gefehlt, ich war mit meinem ersten Beitrag so unsicher und wollt kein Müll plappern... aber selbiges hat mich doch Scott auch gelehrt...

Hm...