Exception werfen beim Aufruf einer virtuellen Methode

phlox81

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.

Simon2

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.

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

Simon2

Freak_Coder schrieb:

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.

DEvent

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

LordJaxom

DEvent schrieb:

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?"

Spacelord

Simon2 schrieb:

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

phlox81

Spacelord schrieb:

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)

Jester

Simon2 schrieb:

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.

Simon2

Jester schrieb:

...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 sind sie eben keine As.
So einfach ist das.

Mit Mehrfachvererbung (oder meinetwegen JavaInterfaces) kann man durchaus Teilfunktionalitäten vererben und das ist nicht wirklich komplizierter , dafür aber "entwicklungssicherer" (weiß der Nachfolgeprogrammierer in 2 Jahren wirklich noch, warum da ein throw steht und wer sich alles darauf verlässt ? Oder wie alle möglichen Aufrufer sich darauf verlassen ? ...).

Natürlich will ich niemanden verteufeln oder prinzipiell zu einem schlechten Programmierer erklären, der sowas macht, aber das sehe ich eher als "Zugeständnis an eine schmutzige Praxis" (in der Dinge wie "Terminzwang", "technische Beschränkungen der Entwicklungsumgebung", "idiotische Firmenvorgaben" etc. eine Rolle spielen).
Eines, das man nur machen sollte, wenn man mit dem Rücken zur Wand steht ... und ein Messer am Hals hat ... ein sehr, sehr scharfes Messer.

Gruß,

Simon2.

GPC

Hm, ich glaube es ist jetzt kein besonders schlimmes Design-Verbrechen. Die Welt hat eben Ecken und Kanten, und das Programm bildet ja nur die Welt ab

Simon2 schrieb:

Eines, das man nur machen sollte, wenn man mit dem Rücken zur Wand steht ... und ein Messer am Hals hat ... ein sehr, sehr scharfes Messer.

Na ja, so schlimm wie Methodenpointer casten, ist's ja jetzt doch net

MfG

GPC

Simon2

GPC schrieb:

Hm, ich glaube es ist jetzt kein besonders schlimmes Design-Verbrechen....

OK, es gibt Schlimmere.
Aber mir ging es hier auch noch um den Zusammenhang im Thread:
Hier entwirft gerade offensichtlich ein noch nicht besonders erfahrener C++-Programmierer (ist nicht böse gemeint, sind wir alle letztlich) ein Programm und ihm kommt zur Lösung seines Problems die "offensichtliche Lösung" in den Sinn.
Ich wollte ihn einfach mal auf eine andere (IMO vielversprechendere) "Lösungsmöglichkeit" hinweisen.
Ob der das tatsächlich macht, bleibt ihm ganz allein überlassen.

Gruß,

Simon2.

Jester

Simon2 schrieb:

Jester schrieb:

...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 sind sie eben keine As.
So einfach ist das.

Jo, so einfach ist das. Einfach und falsch. Lies doch zum Beispiel mal Multi-Paradigm Design for C++. Stichwort: negative variability. Vielleicht liefert auch google was dazu.

edit:

Beispiel aus dem Buch: eine Message-Klasse. Davon erben unterschiedliches Messages. Messages haben üblicherweise einen body. Nur manche messages sind Ausnahmen, die haben keinen body (es sind ganz wenige und messages sind es trotzdem). Soll jetzt die Basisklasse etwa keine Funktion zum Zugriff aus den body bieten? Willste lieber bei jeder normalen Message nen downcast reinbaun? Also den üblichen Fall verkomplizieren?

Simon2

Jester schrieb:

...Jo, so einfach ist das. Einfach und falsch...

"Für jedes noch so komplizierte Problem gibt es eine Lösung, die einfach, allgemeinverständlich, logisch und falsch ist."
(Prof. H. Lesch)

Wie schon gesagt: Es mag in der Praxis und im Spezialfall die am wenigsten schlechte Lösung sein, aber als "Normalfall" kann ich es trotzdem nicht sehen.
Ich sage mal so: Wenn so etwas in einem Anfängerprogramm auftaucht, gibt es in mindestens 80% der Fälle eine bessere Lösung.
Zu Deinem Fall (Ja, ich kenne das Buch NICHT): D.h. bei den "bodylosen Messages" mußt Du jede "body-bezogene Funktion" auf Dauer pflegen und in allen Zusammenhängen, in denen Du Messages nutzt, daran denken, dass es welche gibt/geben könnte, die keinen haben und entsprechende "Sonderlocken" berücksichtigen.

Darin kann ich keinen Vorteil sehen.
Mal abgesehen davon, dass wir hier schlechte Erfahrungen damit gemacht haben, "Messages" zu allzu selbständigen Objekten zu machen, sehe ich nicht, wieso man nicht die Hierarchie entsprechend erweitern sollte auf "BodyLessMessage" und "BodyFullMessage" oder schon die Messageklasse mit der "Optionalität" zu versehen (sprich: eine "virtual bool hasBody() = 0").
In beiden Fällen wäre alles klar.

Gruß,

Simon2.

Jester

Beide Fälle verdecken die eigentliche Gemeinsamkeit und spielen sie in den Hintergrund, obwohl sie sich nur in einer Kleinigkeit unterscheiden.

Es kann in manchen Fällen die beste Lösung sein. So ist das nunmal, auch wenn es vielleicht nicht in ein wunderschönes Weltbild in dem es nur positive Variabilität gibt hineinpaßt. Natürlich ist das kein Normalfall, aber es ist durchaus möglich und dieses absolute "klare Sache, das muß ein Designfehler sein" wollte ich so nicht stehen lassen.

Vielleicht kannst Du James O. Coplien aber auch mal ne eMail schreiben, daß die Lösung so einfach ist und auch fragen, warum er dann ein Buch geschrieben hat in dem sowas behandelt wird.

Simon2

Hi,

ich weiß nicht, warum Du unbedingt einen Konflikt zwischen uns konstruieren willst. In NICHTS widersprichst Du mir inhaltlich und ich nicht Dir.

So what's the point ?

Eigentlich würde mich mehr interessieren, wie es mit bluehart nun eigentlich weitergegangen ist.

Gruß,

Simon2.

Jester

Ich sehe durchaus einen Unterschied zwischen dem was Du schreibst und dem was ich schreibe. Aber wenn das für Dich gleich ist soll mir das auch recht sein.

Simon2

peace

Gruß,

Simon2.

Nachdem wieder alles hier PEACE ist habe ich noch zwei Vorschläge.
Würde zwar das Design was ändern aber was solls ...

class RealA
{
public:
   // Ohne eine berechneBla-Funktion für Klassen die die Func nicht benötigen
};

class A : public RealA
{
public:  // Hier mit berechneBla(...)
  virtual float berechneBla(double, double);
};

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

class C : public RealA
{
public:
   ...
};

Wenns wirklich nur drei Klassen sind dann könnte man es ja auch einfach so machen. Wenn eine Klasse wirklich nicht die Funktion braucht, dann halt eben nicht in die Basisklasse packen ...
(Auch wenn das jetzt nicht vielleicht schön ist, aber ich weiß ja nicht was die Klassen in Wirklichkeit darstellen sollen)

class A {
    public: 
            ...
};

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

class C : public A
{
public:
   ...
};

Alles IMHO schöner als irgendwelche Exceptions.
(Und jetzt kommt Simon2 und sagt mir was nicht schön ist )

Edit->Egal()

blueheart schrieb:

An der Klassenhierachie wollte ich so nichts ändern.

Upps es jetzt gesehen, aber egal

blueheart

Simon2 schrieb:

Hier entwirft gerade offensichtlich ein noch nicht besonders erfahrener C++-Programmierer (ist nicht böse gemeint, sind wir alle letztlich) ein Programm und ihm kommt zur Lösung seines Problems die "offensichtliche Lösung" in den Sinn.

Ja, ja es ist wohl wirklich sehr offensichtlich. Ich fange gerade mit meinem ersten größeren Projekt an. Da hat es anfangs so an ziemlich allem gehapert. Aber ich gebe mir Mühe das auch wirklich alles zu verstehen und um besten umzusetzen.
Allerdings muss ich zu dem Design sagen, dass das so vorgegeben ist. Also es sollen alle Objekte folgendenmaßen erschaffen werden:
A * einer = new B;
oder
A * nocheiner = new C;

Simon2 schrieb:

Eigentlich würde mich mehr interessieren, wie es mit bluehart nun eigentlich weitergegangen ist.

Ich habe mich nun erstmal dazu entschieden, in der Klasse die die Methode nicht verwendet, die Methode erst gar nicht hineinzuschreiben. In der Basisklasse A arbeite ich nun mit einer leeren Anweisungsliste. Wobei ich hier, eigentlich einen Wert zurückgeben müßte, da es sich ja nicht um eine void Methode handelt.
-> Warnmeldungen von Compiler vorprogrammiert. -> also wahnsinnig schlechte Idee. Aber zumindest passiert so während der Laufzeit einfach gar nichts, wenn ein Objekt die Methode aufruft.
Ich finde es schon sehr interessant, was ich hier für eine Diskussion ausgelöst habe. Ich habe auch die anderen Ideen mal ausprobiert.
Gut Ding braucht Weile

Schöne Grüße an alle