3. Exception werfen beim Aufruf einer virtuellen Methode

Exception werfen beim Aufruf einer virtuellen Methode

  • B

    Erstmal die Klassenhierachie die ich verwende:

    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. 🙂

    0
  • S

    bin mir nicht sicher ob der stil so gut ist, aber geht sowas denn nicht?

    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 😉

    0
  • G

    Hallo,

    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

    0
  • S

    Hi,

    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.

    0
  • B

    GPC schrieb:

    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

    0
  • G

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

    0
  • A

    GPC schrieb:

    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

    0
  • S

    GPC schrieb:

    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.

    0
  • ?

    Err, jupp. Aber von Basisklassenzeigern sprach bisher auch noch niemand 😉 :p

    Simon2 schrieb:

    Edith: 2l8 !!

    Grüß Edith von mir 😉

    0
  • S

    GPC|off schrieb:

    ...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.

    0
  • B

    tja, eigentlich wollte ich mit den Objekten der Klasse B und C arbeiten.

    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

    0
  • G

    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.

    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

    0
  • L

    Tja, wenn Du uns Deine Probleme nicht mitteilst, wirst Du wohl nie zu einer funktionierenden Lösung kommen (auch wenn es sie gibt, und eigentlich sehr trivial ist sowie hier schonmal gepostet wurde).

    0
  • S

    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.

    0
  • P

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

    0
  • S

    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.

    0
  • S

    GPC schrieb:

    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!

    0
  • P

    Simon2 schrieb:

    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.

    0
  • S

    phlox81 schrieb:

    ...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.

    0
  • ?

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

    0
Anmelden zum Antworten