class A
{
public:
  virtual float berechneBla(double, double);
};

class B : public A
{
public
  float berechneBla(double, double);
};

class C : public A
{
public:
  float berechneBla(double, double);
};

Nun möchte ich die Methode allerdings nur in der Klasse C aufrufen. Ein Aufruf in Klasse B soll zur Exception führen. (Was kann man eigentlich in dem Fall mit dem Rückgabewert machen?) An der Klassenhierachie wollte ich so nichts ändern. Ich dachte mir das ich das mit einer Exception abfangen könnte, habe es aber bis jetzt leider noch nicht hinbekommen.

Desweiteren wollte ich eine eigene Exception-Klasse für dieses Problem schreiben. So und nun weiß ich leider nicht mehr weiter. Bücher, FAQ's und Google-Suche haben mich leider nicht fündig werden lassen, aber vielleicht weiß ja einer daruaf eine Antwort.

class base
{
  public:
   virtual float test(){return 10.2;}
};

class member:public base
{
 public:
  virtual float test(){throw "Darf hier nicht verwendet werden";};
};

int main(int argc, char* argv[])
{
 base* p = new base;
 try
    {
     try
        {
        p->test();
        }
     catch(const char* ch)
        {
         cout<<ch<<endl;
        }
     }
 __finally
   {
    delete p;
   }

 getch();       return 0;
}
//---------------------------------------------------------------------------

//nicht getestet

[Edit] wenn dann auch richtig

wenn du nicht willst, dass Leute die Methode in B aufrufen, dann mach es so:

class Base {
public:
  virtual void foo();
};

class Derived : public Base
{
  using Base::foo;

public:
  //was auch immer...
};

//... weitere abgeleitete Klassen

Exceptions zu werfen, ist hier imo der falsche Ansatz, denn dann wird der Fehler erst zur Laufzeit auftreten. Anscheinend ist es aber deine Absicht, den Aufruf der Methode ganz zu verbieten, also wäre ein Compile-time Fehler angebrachter.

MfG

GPC

soweit ich weiß, ist "__finally" nicht standardkonform, sondern proprietär (Windows-irgendwas ?). Ansonsten ist das Beispiel schon korrekt, aber nicht ganz auf den Fall des Threaderstellers zugeschnitten.

#include <exception>
class A
{
  public:
   virtual float test(){return 10.2;}
};

class B :public base
{
 public:
  virtual float test(){return 11.2; };
};

class C :public base
{
 public:
  virtual float test(){throw std::runtime_error("Darf nicht aufgerufen werden") ;};
};

int main(int argc, char* argv[])
{
    A* p = new C;
    try {
       p->test();
    }
    catch(std::runtime_error& e) {
        cout<<e.what() <<endl;
        delete p;
    }
    catch(...) {
        delete p;
        throw;
    }
    delete p;
    getch();
    return 0;
}

//nicht getestet

Aber GPCs Vorschlag finde ich auch nicht schlecht....

Gruß,

Simon2.

class Derived : public Base
{
  using Base::foo;

public:
  //was auch immer...
};

//... weitere abgeleitete Klassen

Hi, leider verstehe ich diese Lösung nicht wirklich. Ok ich gebe die Methode foo aus der Klasse Base bekannt. Aber die war doch auch schon vorher bekannt? Tut mir leid aber ich verstehe den Ansatz schon gar nicht.

MfG

Mein Code sagt einfach, dass die Methode foo in der Klasse Derived ab jetzt privat ist

Das funktioniert aber nur solange, wie nicht mit Basisklassen-Zeigern gearbeitet wird.

bis bald
akari

Mein Code sagt einfach, dass die Methode foo in der Klasse Derived ab jetzt privat ist

Hmmm, aber verhindert das nicht nur den "statischen Aufruf" (also, wenn der statische Typ C ist) ?
Ich glaube nicht, dass das gegen das o.g. Verhalten (via Basisklassen-Pointer) schützt.

Edith: 2l8 !!

Gruß,

Simon2.

Simon2 schrieb:

Edith: 2l8 !!

Grüß Edith von mir

...Aber von Basisklassenzeigern sprach bisher auch noch niemand :p

Nanana:

ser1al schrieb:

...

...
 base* p = new base;
...

und ehrlich gesagt: Wer macht schon Polymorphie anders ? :p

GPC|off schrieb:

...
Grüß Edith von mir

Gruß zurück

Gruß,

Simon2.

Aber mein Kopf will irgendwie nicht mehr an eine richtige Lösung glauben.
(immer diese Fehlermeldungen )
Trotzdem mit eurer hilfe werde ich es wohl doch vielleicht noch hinbekommen.

Werde denn mal zum schluss meine lösung dazu posten

GPC|off schrieb:

...Aber von Basisklassenzeigern sprach bisher auch noch niemand :p

Nanana:

ser1al schrieb:

...
[cpp]
...
base* p = new base;
...

Oha, richtig. ser1als Code hatte ich nur überflogen.

und ehrlich gesagt: Wer macht schon Polymorphie anders ? :p

klaro, ihr habt ja auch recht. Dennoch find ich den Exception Ansatz nicht wirklich toll... Während man halt so mit dem Programm arbeitet, poppt ne MessageBox hoch: "Boink. Der Programmierer hat eine Methode verwendet, die er nicht verwenden darf, ich mach Feierabend." ^^

Grüße

GPC

...Dennoch find ich den Exception Ansatz nicht wirklich toll...

Dem stimme ich uneingeschränkt zu.

blueheart schrieb:

...mein Kopf will irgendwie nicht mehr an eine richtige Lösung glauben....

Das (und GPCs Bauchschmerzen) wird vermutlich daran liegen, dass Du "unsauber designt hast". Wenn B und C von A erben, heißt das, dass sie beide "ein A sind".
Wenn dann A eine virtuelle Funktion f() hat, heißt dass das "jedes A auch f() kann".
Da nun "jedes C ein A ist", und "jedes A f() kann" => "C kann f()".

Wenn Du nun zu dem Schluß kommst, C soll "f() nicht können", hast Du irgendwo einen Denkfehler gemacht. Entweder "kann nicht jedes A f()" oder "C ist kein A"....

Denk' Dir das nochmal durch.

Gruß,

Simon2.

Wenn in A die Methode pure virtual ist, müsste es doch mit dem Verschieben
der Methode in den private Bereich klappen, oder?

Das Problem ist eher, dass wir hier von Laufzeitpolymorphie sprechen. Und der kann man leider weder mit Compilezeit- (und dazu zählt die Zugriffskontrolle via private) noch mit Linkzeit-sicherungsmechanismen (wie einer undefinierten pure virtual function) sinnvoll beikommen.
Erst zur Laufzeit entscheidet sich, ob der Basisklassenpointer auf ein B oder ein C zeigt...

Gruß,

Simon2.

Simon2 schrieb:

GPC|off schrieb:

...Aber von Basisklassenzeigern sprach bisher auch noch niemand :p

Nanana:

ser1al schrieb:

...
[cpp]
...
base* p = new base;
...

Oha, richtig. ser1als Code hatte ich nur überflogen.

Grüße

GPC

hehe, eigentli wollte ich da member schrieben

Simon2 schrieb:

GPC schrieb:

...Dennoch find ich den Exception Ansatz nicht wirklich toll...

Dem stimme ich uneingeschränkt zu.

Gruß,

Simon2.

und das habe ich ja auch gesagt, das ich den stil nicht gut finde...dennoch wollte ich ihm sagen das es schon funktioniert!

phlox81 schrieb:

Wenn in A die Methode pure virtual ist, müsste es doch mit dem Verschieben
der Methode in den private Bereich klappen, oder?

Das Problem ist eher, dass wir hier von Laufzeitpolymorphie sprechen. Und der kann man leider weder mit Compilezeit- (und dazu zählt die Zugriffskontrolle via private) noch mit Linkzeit-sicherungsmechanismen (wie einer undefinierten pure virtual function) sinnvoll beikommen.
Erst zur Laufzeit entscheidet sich, ob der Basisklassenpointer auf ein B oder ein C zeigt...

Gruß,

Simon2.

hm, stimmt...

Dann bleibt nur die Exception, oder in B eine leere Methode implementieren, der Aufruf tut dann nix.

...in B eine leere Methode implementieren, der Aufruf tut dann nix.

Ist nicht wirklich besser - nur eine andere Form vom "broken contract" (dann schon lieber eine exception; da hat der Anwender zwar die AKarte gezogen, aber immerhin merkt irgendjemand, dass unerwünschtes Verhalten vorliegt).

Aber wie gesagt: Ich denke, dass hier einfach ein Designfehler vorliegt, den es zu beheben gilt.

Gruß,

Simon2.

Wieso nicht einfach in C die Methode Nicht definieren.
Jeder Aufruf würde dann zu einem Linker-Error führen ...

Wie gesagt: Weils nicht klappt.
Einerseits kann es der Linker gar keinen Fehler feststellen (ein entsprechender Aufruf würde mir A::f() verbunden), andererseits kann der Linker nicht feststellen, was erst zur Laufzeit feststeht.

Gruß,

Simon2.

Während man halt so mit dem Programm arbeitet, poppt ne MessageBox hoch: "Boink. Der Programmierer hat eine Methode verwendet, die er nicht verwenden darf, ich mach Feierabend." ^^

Hehe ich stell mir das grade mit so einem Programm wie Word oder PaintshopPro vor

Hehe ich stell mir das grade mit so einem Programm wie Word oder PaintshopPro vor

Wäre allemal aufschlussreicher als "OpenOffice.exe hat ein Problem verursacht und muss beendet werden. Möchten Sie einen Problembericht an Microsoft senden?"

GPC schrieb:

...Dennoch find ich den Exception Ansatz nicht wirklich toll...

Dem stimme ich uneingeschränkt zu.

blueheart schrieb:

...mein Kopf will irgendwie nicht mehr an eine richtige Lösung glauben....

Das (und GPCs Bauchschmerzen) wird vermutlich daran liegen, dass Du "unsauber designt hast". Wenn B und C von A erben, heißt das, dass sie beide "ein A sind".
Wenn dann A eine virtuelle Funktion f() hat, heißt dass das "jedes A auch f() kann".
Da nun "jedes C ein A ist", und "jedes A f() kann" => "C kann f()".

Wenn Du nun zu dem Schluß kommst, C soll "f() nicht können", hast Du irgendwo einen Denkfehler gemacht. Entweder "kann nicht jedes A f()" oder "C ist kein A"....

Denk' Dir das nochmal durch.

Gruß,

Simon2.

Auf das Problem stößt man schneller als du denkst.
Schau dir z.B. mal das Kompositum Pattern an.Da sind auch alle Objekte Komponenten....aber Blätter können keine Kinder haben und somit auch keine sinnvolle Implementierung der entsprechenden Methoden bieten.
Somit wäre ja eines der "wichtigsten" Design Patterns ein Designfehler?

Gruß Spacelord

Auf das Problem stößt man schneller als du denkst.
Schau dir z.B. mal das Kompositum Pattern an.Da sind auch alle Objekte Komponenten....aber Blätter können keine Kinder haben und somit auch keine sinnvolle Implementierung der entsprechenden Methoden bieten.
Somit wäre ja eines der "wichtigsten" Design Patterns ein Designfehler?

Gruß Spacelord

Nein, die Komposition leitest du von einer Basisklasse ab, welche nur die für Blatt benötigten Methoden besitzt.
Siehe auch http://de.wikipedia.org/wiki/Kompositum_(Entwurfsmuster)

Aber wie gesagt: Ich denke, dass hier einfach ein Designfehler vorliegt, den es zu beheben gilt.

Das kann man so nicht sehen, dazu müßten wir mehr Informationen haben. Manchmal können eben doch alle As irgendwas. Nur eine Ausnahme gibt es: Cs sind zwar As, aber eine einzige Funktion unterstützen sie doch nicht. Dann lieber sowas, als eine furchtbar komplizierte Lösung, die die Gemeinsamkeiten, die vielleicht doch bestehen verdeckt.