namespace foo{
	int bar(){}
};

class Base{
private:
	short bar;
};

class Derived:public Base{
public:
	void test(){
		using namespace foo;
		int a = bar();
	}
};

GCC meint dazu :

error: short int Base::bar' is private error:((Base*)this)->Base::bar' cannot be used as a function

Ist das ein Fehler im GCC oder soll das so sein?

Die Version ist:

g++ (GCC) 3.4.2 (mingw-special)

Ist das ein Fehler im GCC oder soll das so sein?

nö, 1 oder 2 Fehler in deinem Code

Edit: Der C++ Compiler nimmt immer des an, was grad im Scope ist und der Bezeichner bar aus Base überlagert aufgrund der Vererbung immer den Bezeichner bar aus dem Namespace foo.

In der fraglichen Zeile ist nur foo::bar zugänglich also sehe ich nicht wieso er meckert.

Fals dieses Verhalten wirklich so sein sollte dann würde das bedeuten, dass man durch das verändern der privaten Teile einer Basisklasse abgeleitete Klassen brechen kann.

Der C++ Compiler kann ja von Haus aus net wissen, welchen Bezeichner du jetzt gemeint hast (bar aus Base oder bar aus foo), d.h. gibt es eben best. Regeln, welcher Bezeichner zuerst herangezogen wird. In dem Fall wird halt bar aus Base zuerst herangezogen und gcc erkennt, dass das B00lshit is ne Variable auf die Art und Weise zu verwenden.

ko, nochmal. Ich nehme an du willst die Funktion bar im namespace foo aufrufen...

Was da passiert weiß ich. Der GCC bringt diesbezüglich ja eine recht eindeutige Fehlermeldung. Die Frage war ob dieses Verhalten standardkonform ist.

bluecode schrieb:

Der C++ Compiler kann ja von Haus aus net wissen, welchen Bezeichner du jetzt gemeint hast

Und ob er das kann! Derived kann per Definition nicht auf die privaten Elemente von Base zugreifen. Also dürfte Base::foo gar nicht einmal in Betracht kommen.

Fals dieses Verhalten wirklich korrekt ist dann wechsele ich zu m_ aus technischen Gründen.

Fals dieses Verhalten wirklich korrekt ist dann wechsele ich zu m_ aus technischen Gründen.

Imho ist das standardkonform, aber kA wo dein Problem damit ist Ist aus dem Beispiel auch net ersichtlich...

void foo(){}

class A{
public:
  void set_dingsda(int new_bar){ bar = new_bar; }
private:
  int bar;
};

class B:public A{
public:
  void prob(){
    foo();
  }
};

So nun begint man A zu dokumentieren und stellt fest, dass es besser wäre wenn bar foo heißen würde da dies ein aussagekräftiger Name ist. bar ist nicht Teil der Schnittstelle da private, also sollte die Veränderung nur klasseninterne Auswirkungen haben.

void foo(){}

class A{
public:
  void set_dingsda(int new_foo){ foo = new_foo; }
private:
  int foo;
};

class B:public A{
public:
  void prob(){
    foo();
  }
};

Falsch gedacht. B wird dadurch gebrochen.

B kann durchaus eine Klasse ganz wo anders sein und von jemand anderem gewartet werden, der dann mal ordentlich anfängt zu fluchen, wieso jetzt auf einmal Code, der vorher einbahnfrei funktionierte, nicht mehr will.

Das heißt also entweder sämtliche Member pre- oder postfixen oder massiv Pimpl einsetzen um Namenskonflikte zu vermeiden. Beides nicht sonderlich elegant.

Und selbst wenn: Dann macht man halt per Search & Replace ne volle Qualifikation und die Sache ist gegessen.

bluecode schrieb:

Der C++ Compiler kann ja von Haus aus net wissen, welchen Bezeichner du jetzt gemeint hast

Und ob er das kann! Derived kann per Definition nicht auf die privaten Elemente von Base zugreifen. Also dürfte Base::foo gar nicht einmal in Betracht kommen.

Fals dieses Verhalten wirklich korrekt ist dann wechsele ich zu m_ aus technischen Gründen.

Das Problem bei dieser Begründung ist aber, daß Sichtbarkeit (welche Namen sind verfügbar?) und Schutzbedingungen (auf welche Elemente darf ich zugreifen?) unabhängig voneinander geprüft werden - zuerst wird festgestellt, welche Objekte sichtbar sind, danach werden die Zugriffsrechte auf diese Objekte kontrolliert.

vielleicht wirds klarer, wenn man sich mal bewusst wird, was Vererbung eigentlich bedeutet. Alles von der Basisklasse wird weitervererbt. Auch die privaten Elemente. Diese sind zwar nicht sichtbar, aber trotzdem in der Kindklasse vorhanden.

Es ist also quasi EIN Objekt, auch wenn Vererbung und zwei Klassen im Spiel sind.

Daher versucht der Compiler immer zuerst auf die eigenen Variablen zuzugreifen. Das ist aber eine private Methode, und daher kann er nicht darauf zugreifen.

Dasist kein Verstoß gegen OO, sondern ein OO-Designfehler.

Ich weiß nicht ob es die Möglichkeit in C++ gibt, aber z.B. in Java oder auch in C# ist es möglich mit dem Schlüsselwort "new" neue Methoden/Variablen einzuführen, und die "alten" zu vergessen. Aber auch das ist nicht die "feine Art".

Gruß
Norman-Timo