C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ (German) View previous topic :: View next topic   Author Message Boris Glawe Guest Posted: Wed Mar 16, 2005 5:32 pm    Post subject: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Hallo, ich benutze häufig Klassen als Interfaces, d.h. die definierten Methoden sind alle virtual und gleich 0 gesetzt, d.h. sie sind alle nicht implementiert. Einen Konstruktor ist in der Klasse meistens nicht definiert, genausowenig wie einen Destruktor. Mit dem gcc 3.4 läuft das ohne Probleme, und mein Code tut auch, was er soll. Der gcc 4.0, wie er jetzt in Fedora Core 4 test1 Linux ausgeliefert wird, beschwert sich mit einer Warnung, dass die betroffene Klasse virtuelle Methoden, aber keinen viruellen Destruktor hat. Ist das ein Fehler in gcc 4.0, oder mache ich etwas falsch? Da ich die Klasse ja sowieso nicht instanzieren kann, wird auch nie der Destruktor zur Ausführung kommen und die Klasse, die von meinem Interface ableitet muss schließlich einen virtuellen Destruktor haben, weil sie durch das Ableiten auch virtuelle Methoden enthält, womit der Compiler dann wieder zufrieden sein sollte. Wo liegt also der Fehler? Bei meinem Programmierstil, oder soll ich einen Bugreport bei gcc einreichen? Grüße Boris -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Markus Schaaf Guest Posted: Wed Mar 16, 2005 6:22 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces "Boris Glawe" <boris (AT) boris-glawe (DOT) de> schrieb: Quote: Der gcc 4.0, wie er jetzt in Fedora Core 4 test1 Linux ausgeliefert wird, beschwert sich mit einer Warnung, dass die betroffene Klasse virtuelle Methoden, aber keinen viruellen Destruktor hat. Wo liegt also der Fehler? Bei meinem Programmierstil, oder soll ich einen Bugreport bei gcc einreichen? Diese Warnung hat die gleiche Qualität wie die bei: if( f = fopen( fileName, "r" ) ) ... Solange Du weißt was Du tust, kannst Du sie also ignorieren. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Martin Winkler Guest Posted: Wed Mar 16, 2005 6:29 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Markus Schaaf wrote: Quote: "Boris Glawe" <boris (AT) boris-glawe (DOT) de> schrieb: Der gcc 4.0, wie er jetzt in Fedora Core 4 test1 Linux ausgeliefert wird, beschwert sich mit einer Warnung, dass die betroffene Klasse virtuelle Methoden, aber keinen viruellen Destruktor hat. Wo liegt also der Fehler? Bei meinem Programmierstil, oder soll ich einen Bugreport bei gcc einreichen? Diese Warnung hat die gleiche Qualität wie die bei: if( f = fopen( fileName, "r" ) ) ... Solange Du weißt was Du tust, kannst Du sie also ignorieren. Beim Stichwort "Interface" klingelt es aber bei mir. Das hört sich an, als ob über Pointer auf die (abstrakte) Basisklasse auf die konkreten Objekte zugegriffen wird. Und dann reicht es meines Wissens nicht aus, wenn der Destruktor der abgeleiteten Klasse virtuell ist, sondern der der Basisklasse muß es auch schon sein. Insofern würde ich auf den Begriff "Programmierstil" anspielen und wärmstens empfehlen, einen virtuellen Destruktor (der leer sein kann) zu implementieren. Gruß Martin -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Marcel Müller Guest Posted: Wed Mar 16, 2005 6:32 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Hallo, Boris Glawe schrieb: [Interfaces] Quote: Mit dem gcc 3.4 läuft das ohne Probleme, und mein Code tut auch, was er soll. Der gcc 4.0, wie er jetzt in Fedora Core 4 test1 Linux ausgeliefert wird, beschwert sich mit einer Warnung, dass die betroffene Klasse virtuelle Methoden, aber keinen viruellen Destruktor hat. Kenne ich, hatte ich auch schon bei anderen Compilern (evtl. auch gcc 3.?). Quote: Ist das ein Fehler in gcc 4.0, oder mache ich etwas falsch? Naja... #include <ostream> using namespace std; struct Iirgendwas { virtual void foo() =0; }; class MyClass : public virtual Iirgendwas {public: MyClass() { cout << "Konstruktor"; } virtual ~MyClass() { cout << "Destruktor"; } virtual void foo(); }; int main() { Iirgendwas* p = new MyClass(); delete p; // MyClass Destruktor wird nicht aufgerufen! return 0; } ===== Ausgabe Konstruktor ===== Quote: Da ich die Klasse ja sowieso nicht instanzieren kann, wird auch nie der Destruktor zur Ausführung kommen und die Klasse, die von meinem Interface ableitet muss schließlich einen virtuellen Destruktor haben, weil sie durch das Ableiten auch virtuelle Methoden enthält, womit der Compiler dann wieder zufrieden sein sollte. Nein, s.o. Quote: Wo liegt also der Fehler? Bei meinem Programmierstil, oder soll ich einen Bugreport bei gcc einreichen? Wenn man die Java- bzw. C#-Logik für Interfaces nachbilden will, muß - von allen Interfaces virtuell geerbt werden und - jedes Interface einen leeren, virtuellen Destruktor haben. -- Marcel Müller -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Falk Tannhäuser Guest Posted: Wed Mar 16, 2005 6:50 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Boris Glawe wrote: Quote: Der gcc 4.0, wie er jetzt in Fedora Core 4 test1 Linux ausgeliefert wird, beschwert sich mit einer Warnung, dass die betroffene Klasse virtuelle Methoden, aber keinen viruellen Destruktor hat. Ist das ein Fehler in gcc 4.0, oder mache ich etwas falsch? An und für sich ist es nicht falsch, keinen virtuellen Destruktor zu haben, es sei denn, man führt ein 'delete' einer Instanz einer abgeleiteten Klasse über einen Basisklassenzeiger aus - dann gibt's das allseits (un)beliebte "nicht definierte Verhalten". Letzteres ist zwar für den Compiler kaum zu detektieren, doch kommt es erfahrungsgemäß häufig vor, wenn ersteres zutrifft - daher wurde freundlicherweise dem Compiler die besagte Warnung beigebracht. (Ob der Destruktor dabei ganz leer ist, ist dafür unerheblich.) Solange du letzteres, also BaseClass* pBase = new DerivedClass(/* ... */); // ... delete pBase; mit absoluter Sicherheit niemals tust, kannst du die Warnung ignorieren. Praktisch erscheint es mir aber nicht unbedingt einfach, solche Objekte stets über einen Zeiger mit dem richtigen Typen zu deleten (es sei denn, sie werden nie dynamisch erzeugt - ist aber selten). Quote: Da ich die Klasse ja sowieso nicht instanzieren kann, wird auch nie der Destruktor zur Ausführung kommen Doch, er wird ja stets vom Destruktor der abgeleiteten Klasse zum Schluss aufgerufen. Das ist aber nicht das eigentliche Problem - definierst du in der Basisklasse keinen Destruktor, tut's der Compiler, bloß ist er dann eben nicht virtuell. Quote: und die Klasse, die von meinem Interface ableitet muss schließlich einen virtuellen Destruktor haben, weil sie durch das Ableiten auch virtuelle Methoden enthält, womit der Compiler dann wieder zufrieden sein sollte. Wo liegt also der Fehler? Bei meinem Programmierstil, oder soll ich einen Bugreport bei gcc einreichen? Sei froh, dass du diese Warnung bekommst! Der Mehraufwand für das Hinzufügen eines virtuellen Destruktors in der Basisklasse ist höchst minimal, sofern es in dieser sowieso schon virtuelle Funktionen (und damit eine Vtable sowie in jeder Instanz einen Zeiger auf selbige) gibt, und du ersparst dir möglicherweise viel Ärger. MfG Falk -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Thomas Mang Guest Posted: Wed Mar 16, 2005 7:00 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces "Boris Glawe" <boris (AT) boris-glawe (DOT) de> schrieb im Newsbeitrag news:d19qil$spo$1 (AT) newsreader2 (DOT) netcologne.de... Quote: Hallo, ich benutze häufig Klassen als Interfaces, d.h. die definierten Methoden sind alle virtual und gleich 0 gesetzt, d.h. sie sind alle nicht implementiert. Einen Konstruktor ist in der Klasse meistens nicht definiert, genausowenig wie einen Destruktor. Mit dem gcc 3.4 läuft das ohne Probleme, und mein Code tut auch, was er soll. Der gcc 4.0, wie er jetzt in Fedora Core 4 test1 Linux ausgeliefert wird, beschwert sich mit einer Warnung, dass die betroffene Klasse virtuelle Methoden, aber keinen viruellen Destruktor hat. Ist das ein Fehler in gcc 4.0, oder mache ich etwas falsch? Da ich die Klasse ja sowieso nicht instanzieren kann, wird auch nie der Destruktor zur Ausführung kommen und die Klasse, die von meinem Interface ableitet muss schließlich einen virtuellen Destruktor haben, weil sie durch das Ableiten auch virtuelle Methoden enthält, womit der Compiler dann wieder zufrieden sein sollte. Wo liegt also der Fehler? Bei meinem Programmierstil, oder soll ich einen Bugreport bei gcc einreichen? Höchstwahrscheinlich in Deinem Stil. Ob eine Klasse virtuelle Funktionen hat oder nicht ist dem Destruktor egal, wenn der nicht virtuell ist bedeutet daß, das Destruktoren über pointer statisch gelöst werden. z.B. myInterface * p = new trilliTrallaLa; delete p; Sofern myInterface keinen virtuellen Destruktor hat (myInterface ist Deine Klasse) wird der Destruktor von trilliTrallaLa nie aufgerufen. Probier es einfach mal aus, indem der Destruktor von trilliTrallaLa Text ausgibt. Beachte daß sofern Du bereits virtuelle Funktionen hast, der virtuelle Destruktor nichts mehr kostet, Dir aber wahrscheinlich später das Leben rettet, zumindest lange debugging-sessions. Das Vorhandensein von abstrakten Methoden macht den Destruktor nicht virtuell! Thomas -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Markus Schaaf Guest Posted: Wed Mar 16, 2005 7:13 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces "Martin Winkler" <martin_winkler (AT) gmx (DOT) de> schrieb: Quote: Beim Stichwort "Interface" klingelt es aber bei mir. Das hört sich an, als ob über Pointer auf die (abstrakte) Basisklasse auf die konkreten Objekte zugegriffen wird. Das ist in Verbindung mit virtuellen Funktionen immer so, sonst wären sie sinnlos. Quote: Und dann reicht es meines Wissens nicht aus, wenn der Destruktor der abgeleiteten Klasse virtuell ist, sondern der der Basisklasse muß es auch schon sein. Es besteht kein direkter Zusammenhang. Genau wie jede einzelne virtuelle Funktion einen Teil des Interfaces dem Runtime-Dispatch überläßt, so tut das der virtuelle D'tor auch, eben für die Funktion "Löschen eines dynamischen Objekts". Zwar ist die Nutzung dynamischer Objekte in Verbindung mit Runtime-Dispatch üblich, jedoch weder zwingend noch besonders vorteilhaft. Und selbst die Verwendung dynamischer Objekte erfordert nicht zwangsläufig einen Runtime-Dispatch beim Löschen. Wer argumentiert, jede öffentliche Basisklasse sollte einen virtuellen D'tor haben, muß auch argumentieren, daß jede andere Funktion innerhalb der Basisklasse virtuell sein müsse. Tatsächlich ist Runtime-Dispatch aber eine der wenigen Stellen in C++, wo man wirklich für die gewonnene Flexibilität einen Preis zahlt: Sowohl bei jedem Aufruf an Laufzeit, als auch beim Speicherverbrauch, wegen der größeren V-Tables. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Boris Glawe Guest Posted: Wed Mar 16, 2005 7:33 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Falk Tannhäuser wrote: Quote: Boris Glawe wrote: Der gcc 4.0, wie er jetzt in Fedora Core 4 test1 Linux ausgeliefert wird, beschwert sich mit einer Warnung, dass die betroffene Klasse virtuelle Methoden, aber keinen viruellen Destruktor hat. Ist das ein Fehler in gcc 4.0, oder mache ich etwas falsch? An und für sich ist es nicht falsch, keinen virtuellen Destruktor zu haben, es sei denn, man führt ein 'delete' einer Instanz einer abgeleiteten Klasse über einen Basisklassenzeiger aus - dann gibt's das allseits (un)beliebte "nicht definierte Verhalten". Letzteres ist zwar für den Compiler kaum zu detektieren, doch kommt es erfahrungsgemäß häufig vor, wenn ersteres zutrifft - daher wurde freundlicherweise dem Compiler die besagte Warnung beigebracht. (Ob der Destruktor dabei ganz leer ist, ist dafür unerheblich.) Solange du letzteres, also BaseClass* pBase = new DerivedClass(/* ... */); // ... delete pBase; mit absoluter Sicherheit niemals tust, kannst du die Warnung ignorieren. Ahh verstehe: Weil der Destruktor nicht virtual ist, wird anhand des Pointertyps die aufzurufende Methode/ Konstruktor gewählt, wobei dem Compiler jetzt die Implementierung fehlen würde. Mich wundert nur, dass der aktuelle g++ so etwas nicht erkennt, weil er es an anderer Stelle sehr gut erkennt (wenn z.B. nur einige Methoden nicht implementiert sind). Quote: Praktisch erscheint es mir aber nicht unbedingt einfach, solche Objekte stets über einen Zeiger mit dem richtigen Typen zu deleten (es sei denn, sie werden nie dynamisch erzeugt - ist aber selten). Da ich die Klasse ja sowieso nicht instanzieren kann, wird auch nie der Destruktor zur Ausführung kommen Doch, er wird ja stets vom Destruktor der abgeleiteten Klasse zum Schluss aufgerufen. Das ist aber nicht das eigentliche Problem - definierst du in der Basisklasse keinen Destruktor, tut's der Compiler, bloß ist er dann eben nicht virtuell. Ok, hier bin ich davon ausgegangen, dass nur die Implementierung der abgeleiteten Klasse zur Ausführung kommt, weil die Klasse schließlich eine vtab hat. Aber das ist eine falsche Annahme, weil der Destruktor nicht virtuel ist - habe ich jetzt verstanden :-) Quote: Sei froh, dass du diese Warnung bekommst! Der Mehraufwand für das Hinzufügen eines virtuellen Destruktors in der Basisklasse ist höchst minimal, sofern es in dieser sowieso schon virtuelle Funktionen (und damit eine Vtable sowie in jeder Instanz einen Zeiger auf selbige) gibt, und du ersparst dir möglicherweise viel Ärger. Das ist nur ärgerlich, weil man sich die .cpp Datei sparen könnte, wenn man es nicht implementieren müsste. Werde die leere Implementierung jetzt aber in die Klassendefinition mit aufnehmen, damit ich nicht noch alle Interfaces einzeln kompilieren muss. Grüße und Danke Boris -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Albrecht Fritzsche Guest Posted: Wed Mar 16, 2005 7:41 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Markus Schaaf wrote: Quote: Wer argumentiert, jede öffentliche Basisklasse sollte einen virtuellen D'tor haben, muß auch argumentieren, daß jede andere Funktion innerhalb der Basisklasse virtuell sein müsse. Wieso? Ich verwende recht gerne Basisklassen a lá (PRE + POST sind evtl Pre-, Postkonditionchecks) struct Base { virtual ~Base(){} void something() { PRE; do_first(); do_second(); POST; } protected: virtual void do_first() = 0; virtual void do_second() = 0; }; Hier sollte IMHO something() gerade *nicht* virtuell sein, da die Basisklasse somit die Logik festlegt (erst do_first(), dann do_second()) waehrend die abgeleiteten Klassen nur noch das Verhalten aendern koennen. Daher verstehe ich Deine Behauptung nicht. Ali -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Boris Glawe Guest Posted: Wed Mar 16, 2005 8:28 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Quote: Das Vorhandensein von abstrakten Methoden macht den Destruktor nicht virtuell! Das war's was ich wissen musste danke Quote: Thomas -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Falk Tannhäuser Guest Posted: Wed Mar 16, 2005 10:08 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Marcel Müller wrote: [...] Quote: { Iirgendwas* p = new MyClass(); delete p; // MyClass Destruktor wird nicht aufgerufen! Wobei das nur *eine* der möglichen Auswirkungen von "nicht definiertem Verhalten" ist. Weitere Effekte können z.B. sein, dass - der Deallokationsfunktion (operator delete) eine falsche Adresse (d.h. eine, die nicht durch den zugehörigen "operator new" zurückgegeben wurde) übergeben wird, insbesondere wenn das Basisklassen-Unterobjekt nicht gleich am Anfang des vollständigen Objekts beginnt (passiert gerne u.a. sowohl bei Mehrfach- als auch bei virtueller Vererbung), - die falsche Deallokationsfunktion aufgerufen wird (falls die abgeleitete Klasse ihren eigenen "operator delete" hat). Diese beiden Probleme können den Heap zerwichsen und damit zum Programmabsturz sofort oder später führen, oder auch "nur" zu korrupten Daten, oder bestenfalls zum Speicherleck... MfG Falk -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Rolf Magnus Guest Posted: Thu Mar 17, 2005 8:02 am    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Markus Schaaf wrote: Quote: Und dann reicht es meines Wissens nicht aus, wenn der Destruktor der abgeleiteten Klasse virtuell ist, sondern der der Basisklasse muß es auch schon sein. Es besteht kein direkter Zusammenhang. Genau wie jede einzelne virtuelle Funktion einen Teil des Interfaces dem Runtime-Dispatch überläßt, so tut das der virtuelle D'tor auch, eben für die Funktion "Löschen eines dynamischen Objekts". Zwar ist die Nutzung dynamischer Objekte in Verbindung mit Runtime-Dispatch üblich, jedoch weder zwingend noch besonders vorteilhaft. Als "besonders vorteilhaft" würde ich sie doch bezeichnen. Das ermöglicht ja erst, daß man z.B. Zeiger auf Objekte aller möglichen von einer Basisklasse abgeleiteten Klassen in einem Container speichern und zur Laufzeit entscheiden kann, welcher Klasse jedes dieser Objekte angehört. Ich verwende Polymorphie verhältnismäßig selten mit Objekten, die nicht dynamisch allokiert sind. Quote: Und selbst die Verwendung dynamischer Objekte erfordert nicht zwangsläufig einen Runtime-Dispatch beim Löschen. Wer argumentiert, jede öffentliche Basisklasse sollte einen virtuellen D'tor haben, muß auch argumentieren, daß jede andere Funktion innerhalb der Basisklasse virtuell sein müsse. Das sieht nicht jeder so wie du. Hatte Stroustrup nicht mal vorgeschlagen, in der nächsten C++-Version bei polymorphen Typen den Destruktor automatisch virtuell zu machen? Quote: Tatsächlich ist Runtime-Dispatch aber eine der wenigen Stellen in C++, wo man wirklich für die gewonnene Flexibilität einen Preis zahlt: Sowohl bei jedem Aufruf an Laufzeit, Nein, nur bei jedem Aufruf über einen Zeiger oder eine Referenz. Bei direkten Aufrufen steht der Typ zur Compilezeit fest, und es ist kein Runtime-Dispatch nötig. Quote: als auch beim Speicherverbrauch, wegen der größeren V-Tables. Allerdings - sofern wir nicht über spezielle Embedded-Systeme sprechen - nur marginal. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Falk Tannhäuser Guest Posted: Thu Mar 17, 2005 8:42 am    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Rolf Magnus wrote: Quote: Markus Schaaf wrote: als auch beim Speicherverbrauch, wegen der größeren V-Tables. Allerdings - sofern wir nicht über spezielle Embedded-Systeme sprechen - nur marginal. Wenn die V-Table sowieso schon vorhanden ist, macht eine zusätzliche virtuelle Funktion einen zusätzlichen Eintrag in der V-Table (also typischerweise 4 Bytes), und selbige existiert einmal per Klasse, nicht per Instanz. Das müsste schon ein *sehr* eingeschränktes System sein, wo man sich den virtuellen Destruktor nicht leisten könnte... MfG Falk -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top dietmar_kuehl@yahoo.com Guest Posted: Thu Mar 17, 2005 10:27 am    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Thomas Mang wrote: Quote: Das Vorhandensein von abstrakten Methoden macht den Destruktor nicht virtuell! .... in üblichen C++ Implementierungen. Ad hoc sehe ich keinen Grund, warum der Destruktor von einer Implementierung nicht automatisch virtuell gemacht werden könnte, wenn die Klasse eine virtuelle Funktion hat. Wenn 'delete' auf ein entsprechendes Objekt angewendet wird, dann gibt es zwei Möglichkeiten: - Der statische Typ des Zeigers stimmt mit dem dynamischen Typ des Objektes überein, und es ist irrelevant, ob der Destruktor virtuell ist. - Der statische Typ des Zeigers stimmt nicht mit dem dynamischen Typ des Objektes überein und es gibt "undefined behavior": die Implementierung würde, da der Destruktor als virtuell behandelt wird, zufällig das richtige machen! -- <mailto:dietmar_kuehl (AT) yahoo (DOT) com> <http://www.dietmar-kuehl.de/> <http://www.contendix.com> - Software Development & Consulting -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Babak Pourat Guest Posted: Thu Mar 17, 2005 12:56 pm    Post subject: Re: gcc 4.0 <=> gcc 3.4 Behandlung von Interfaces Markus Schaaf wrote: Quote: Funktion innerhalb der Basisklasse virtuell sein müsse. Tatsächlich ist Runtime-Dispatch aber eine der wenigen Stellen in C++, wo man wirklich für die gewonnene Flexibilität einen Preis zahlt: Sowohl bei jedem Aufruf an Laufzeit als auch beim Speicherverbrauch, wegen der größeren V-Tables. Ich meine nicht dass es prinzipiell so sein muss: Was ist ist denn die alternative zur späten Bindung? Z. B. ein switch case Block um das richtige Objekt anzuspringen. Ist das wirklich performanter als der Aufruf durch die V-Table? Und verbrauchen viele solcher switch case Blocke nicht auch (viel) speicher? Ich sehe den Nachteil der späten Bindung eher darin dass, inline code aussen vor bleibt. Babak -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (German) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.