C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  array aus unterschieldlichen klassen... Goto page Previous  1, 2, 3, 4  Next          C++Talk.NET Forum Index -> C++ (German) View previous topic :: View next topic   Author Message Thomas Thiele Guest Posted: Wed Sep 20, 2006 3:04 am    Post subject: Re: array aus unterschieldlichen klassen... Bob Hairgrove schrieb: Quote: Werde das morgen mal mit VC++ probieren. Warum? Weil es mich schlicht interessiert. Auch wenn der Fall in der Praxis selten vorkommt, meine ich so was schon gemacht/probiert zu haben. Back to top Tibor Pausz Guest Posted: Wed Sep 20, 2006 9:10 pm    Post subject: Re: array aus unterschieldlichen klassen... Heinz Saathoff schrieb: Quote: Wenn keiner der Klassen in der Ableitung einen Destruktor benötigt, sollte das Verhalten definiert sein. Warum sollte das erfüllt sein? Wenn sizeof(A)!=sizeof(B) ist anzunehmen, daß es knallt. Ratespielchen mit dem Compiler zu veranstalten ist schlecht. Back to top Thomas Thiele Guest Posted: Wed Sep 20, 2006 11:59 pm    Post subject: Re: array aus unterschieldlichen klassen... Thomas Thiele schrieb: Quote: Werde das morgen mal mit VC++ probieren. Knallt auch. Back to top Heinz Saathoff Guest Posted: Thu Sep 21, 2006 12:45 am    Post subject: Re: array aus unterschieldlichen klassen... Moin, Tibor Pausz schrieb... Quote: Wenn keiner der Klassen in der Ableitung einen Destruktor benötigt, sollte das Verhalten definiert sein. Warum sollte das erfüllt sein? Wenn sizeof(A)!=sizeof(B) ist anzunehmen, daß es knallt. Ratespielchen mit dem Compiler zu veranstalten ist schlecht. Mit der Größe der Klassen hat das wohl nichts zu tun, da der Destruktoraufruf und die Speicherfreigabe des Objektes 2 Phasen darstellen. Der Code A *a = new B; //... delete a; ist als B *_temp_b = operator new(sizeof(B)); _temp_b->B(); A *a = _temp_b; //... // hier ist nur der Basistyp van a statisch bekannt, also // generiert der Compiler a->~A(); // Destruktor von A, wenn ~A nicht virtuell operator delete(a); Es ist hier wie bei malloc/free. Die Größe des Objektes ist nur bei der Allokation erforderlich, nicht aber bei der Deallokation. Also, an sizeof(A) != sizeof(B) liegt das undefinierte Verhalten nicht. Das Beispiel, das Falk Tannhäuser anführt, leuchtet schon eher ein, auch wenn daraus ein anderes Fazit als '... die Basisklasse muß einen virtuellen Konstruktor besitzen'. Die Regel könnte dann lauten '... wenn eine der abgeleiteten Klassen eine virtuelle Funktion besitzt, dann muß auch die Basisklasse mindestens eine virtuelle Funktion besitzen'. Es wird sich dann sicher anbieten, den Destruktor virtuell zu machen. - Heinz Back to top Torsten Robitzki Guest Posted: Thu Sep 21, 2006 2:41 am    Post subject: Re: array aus unterschieldlichen klassen... Heinz Saathoff wrote: Quote: B *_temp_b = operator new(sizeof(B)); _temp_b->B(); A *a = _temp_b; //... // hier ist nur der Basistyp van a statisch bekannt, also // generiert der Compiler a->~A(); // Destruktor von A, wenn ~A nicht virtuell operator delete(a); Es ist hier wie bei malloc/free. Die Größe des Objektes ist nur bei der Allokation erforderlich, nicht aber bei der Deallokation. Wer sagt das? Wenn dem Compiler die Größe des freizugebenden Speichers bekannt ist, kann er damit Optimierungen vornehmen. Allokatoren lassen sich effektiver Implementieren, wenn man die Größe auch beim Freigeben hat. Quote: Also, an sizeof(A) != sizeof(B) liegt das undefinierte Verhalten nicht. Das undefinierte Verhalten ist als solches so definiert. Wenn in der Definition der Sprache explizit drin steht, das das Verhalten für diesen oder jehnen Fall nicht definiert ist, ist das Verhalten einfach nicht definiert; nicht mehr, nicht weniger. Quote: Das Beispiel, das Falk Tannhäuser anführt, leuchtet schon eher ein, auch wenn daraus ein anderes Fazit als '... die Basisklasse muß einen virtuellen Konstruktor besitzen'. Die Regel könnte dann lauten '... wenn eine der abgeleiteten Klassen eine virtuelle Funktion besitzt, dann muß auch die Basisklasse mindestens eine virtuelle Funktion besitzen'. Es wird sich dann sicher anbieten, den Destruktor virtuell zu machen. Nein, der Destruktor muß virtuell sein, wenn ein Objekt über einen Zeiger gelöscht wird, dessen statischen Typen nicht dem dynamischen Typen des Objekts entspricht. mfg Torsten Back to top Falk Tannhäuser Guest Posted: Thu Sep 21, 2006 3:00 am    Post subject: Re: array aus unterschieldlichen klassen... Heinz Saathoff schrieb: Quote: Also, an sizeof(A) != sizeof(B) liegt das undefinierte Verhalten nicht. Nein, das undefinierte Verhalten liegt daran, dass der Heilige Standard ausdrücklich aussagt, dass das Verhalten nicht definiert ist Siehe Psalm 5.3.5/3: "[...] if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand's dynamic type and the static type shall have a virtual destructor or the behavior is undefined. [...]" Quote: Das Beispiel, das Falk Tannhäuser anführt, leuchtet schon eher ein, auch wenn daraus ein anderes Fazit als '... die Basisklasse muß einen virtuellen Konstruktor besitzen'. Die Regel könnte dann lauten '... wenn eine der abgeleiteten Klassen eine virtuelle Funktion besitzt, dann muß auch die Basisklasse mindestens eine virtuelle Funktion besitzen'. Es wird sich dann sicher anbieten, den Destruktor virtuell zu machen. Im konkreten Beispiel ist der Programmabsturz darauf zurückzuführen, dass mit B* b = new B; 'b' auf den Anfang des vom entsprechenden 'operator new' zurückgegebenen Speicherbereichs zeigt, während dies 'a' nach A* a = b; nicht unbedingt tun muss; d.h. mit void* pa = a; void* pb = b; muss nicht zwingenderweise (pa == pb) gelten [ungeachtet der Tatsache, dass (a == b) gilt, da bei letzterem Vergleich eine Typumwandlung nach 'A*' erfolgt, wobei die Speicheradresse entsprechend angepasst wird]. Dieses Verhalten tritt, wie gesagt, nicht nur beim Ableiten einer polymorphen von einer nicht polymorphen Klasse auf, sondern (logischerweise!) auch bei Mehrfachvererbung (es sei denn, eine der Basisklassen ist leer und der Compiler optimiert diese im Speicherlayout der Instanzen der abgeleiteten Klasse weg) oder virtueller Vererbung. Die Folge auf typischen Implementierungen ist, dass beim 'delete a;' der Zeigerwert von 'a' an 'operator delete' übergeben wird, womit dieser nichts g'scheit's anfangen kann, da 'a' eben irgendwo in die Mitte des vom 'operator new' zurückgegebenen Speicherblocks zeigt statt, wie es sich gehört, an den Anfang. Folge: Heapkorruption, mit Absturz früher oder später, oder (noch viel schlimmer) mit stillschweigender Datenkorruption... Achso, und wenn in Klasse 'B' nun 'operator new' und 'operator delete' redefiniert worden sind (etwa um Speicherblöcke zwecks Optimierung aus einem besonderen Pool anzufordern und diese nach Gebrauch auch ordnungsgemäß dorthin zurückzugeben), ist der Aufruf von 'B::operator delete' bei einem 'delete a;' auch nur dann garantiert, wenn '~A::A()' virtuell ist. Ansonsten wird wahrscheinlich meist der globale '::operator delete' (bzw. 'A::operator delete', so vorhanden) aufgerufen, was ebenfalls für Unordnung sorgen dürfte. Nun mag jemand sagen: "Ja, aber wenn ich nur Einfachvererbung mache, und keine klassenweisen (De)allokations-Operatoren habe, und niemals polymorphe von nicht polymorphen Klassen ableite, und zum Compilieren stets um Mitternacht bei Vollmond auf den Friedhof gehe und dabei unter Erheben meines USB-Sticks 'Expecto Patronum' ausrufe - siehe <http://minilien.fr/a0jsqh>, und, und, und..." - Experimentieren, was ein bestimmter Compiler wann wie macht, mag oft interessant und auch lehrreich sein - doch kann man daraus leider keine Schlüsse ziehen, welches Verhalten sich mit anderen Compilern, künftigen Compilerversionen , anderen Plattformen bzw. anderen Optionen einstellt. Auch weiß man oft nicht vorherzusagen, wer wann in einem größeren oder länger dauernden Projekt dann doch mal eine virtuelle Funktion oder eine zweite Basisklasse irgendwo einfügt... Kurze Moral: Was im Standard steht, ist (bis auf Ausnahmen...) heilig, und auf dort nicht definiertem Verhalten basierenden Code zu schreiben ist (meistens) bäh. MfG Falk Back to top Tibor Pausz Guest Posted: Thu Sep 21, 2006 7:04 pm    Post subject: Re: array aus unterschiedlichen klassen... Heinz Saathoff schrieb: Quote: Es ist hier wie bei malloc/free. Die Größe des Objektes ist nur bei der Allokation erforderlich, nicht aber bei der Deallokation. Es gibt eine ganze Reihe von Möglichkeiten bei denen es ein Problem darstellt. Denk mal an Placement new. Wichtig ist eigentlich nur ein einziges Gegenbeispiel, mehr braucht es doch nicht zu belegen, daß man Probleme bekommen kann, wenn der Destruktor nicht virtuell ist. Back to top Thomas Dorner Guest Posted: Thu Sep 21, 2006 8:44 pm    Post subject: Re: array aus unterschieldlichen klassen... FT>Achso, und wenn in Klasse 'B' nun 'operator new' und 'operator delete' FT>redefiniert worden sind (etwa um Speicherblöcke zwecks Optimierung aus FT>einem besonderen Pool anzufordern und diese nach Gebrauch auch FT>ordnungsgemäß dorthin zurückzugeben), ist der Aufruf von 'B::operator FT>delete' bei einem 'delete a;' auch nur dann garantiert, wenn '~A::A()' FT>virtuell ist. Ansonsten wird wahrscheinlich meist der globale FT>'::operator delete' (bzw. 'A::operator delete', so vorhanden) FT>aufgerufen, was ebenfalls für Unordnung sorgen dürfte. Korrekt, ich habe mal Dein Beispiel entsprechend erweitert: #include <iostream> #include <ostream> struct A1 { int i; A1() { std::cout << "A1::A1()" << std::endl; } ~A1() { std::cout << "A1::~A1()" << std::endl; } }; struct B1 : public A1 { B1() { std::cout << "B1:B1()" << std::endl; } ~B1() { std::cout << "B1::~B1()" << std::endl; } virtual void foo() {} }; struct A2 { int i; A2() { std::cout << "A2::A2()" << std::endl; } ~A2() { std::cout << "A2::~A2()" << std::endl; } void* operator new(std::size_t sz) { std::cout << "A2::operator new()" << std::endl; return ::operator new(sz); } void operator delete(void* p) { std::cout << "A2::operator delete()" << std::endl; ::operator delete(p); } }; struct B2 : public A2 { B2() { std::cout << "B2:B2()" << std::endl; } ~B2() { std::cout << "B2::~B2()" << std::endl; } void* operator new(std::size_t sz) { std::cout << "B2::operator new()" << std::endl; return ::operator new(sz); } void operator delete(void* p) { std::cout << "B2::operator delete()" << std::endl; ::operator delete(p); } }; int main() { A2* a2 = new B2; delete a2; A1* a1 = new B1; delete a1; std::cout << "Und tschüss!" << std::endl; } Das Ergebnis mit g++ 4.1.0: ~/C/Single> g++ -W -Wall -o polymorphie_w_o_virtual_dump polymorphie_w_o_virtual_dump.cpp && ./polymorphie_w_o_virtual_dump polymorphie_w_o_virtual_dump.cpp:1:1: warning: multi-line comment polymorphie_w_o_virtual_dump.cpp:17: warning: 'struct B1' has virtual functions but non-virtual destructor B2::operator new() A2::A2() B2:B2() A2::~A2() A2::operator delete() A1::A1() B1:B1() A1::~A1() *** glibc detected *** ./polymorphie_w_o_virtual_dump: free(): invalid pointer: Also für diesen Fall noch nicht mal eine Warnung, aber Aufruf eines nicht passenden delete Operators. Frage an die Standard-Experten: Verbietet der Standard einem Compiler, für unterschiedliche Klassen einer Hierarchie intern unterschiedliche new Operatoren zu verwenden, wenn explizit keine in der Klasse definiert sind (z.B. wie schon von Falk angesprochen für Optimierungen)? Falls der Standard dies nicht verbietet, sollte das gezeigte Verhalten theoretisch auch ohne explizit devinierte new/delete Operatoren möglich sein. Viele Grüße, Thomas Back to top Falk Tannhäuser Guest Posted: Fri Sep 22, 2006 12:33 am    Post subject: Re: array aus unterschieldlichen klassen... Thomas Dorner schrieb: Quote: Verbietet der Standard einem Compiler, für unterschiedliche Klassen einer Hierarchie intern unterschiedliche new Operatoren zu verwenden, wenn explizit keine in der Klasse definiert sind (z.B. wie schon von Falk angesprochen für Optimierungen)? Macht er (der Standard, nicht Falk), in §§ 5.3.4/9 (für new) und 12..5/4 (für delete). Die Allokationsfunktion wird zunächst in der betreffenden Klasse gesucht (wo demzufolge auch eine eventuelle ererbte gefunden wird, wenn keine direkt in der Klasse definiert ist). Wird dort keine gefunden, muss der Compiler die globale (also ::operator new), in der Standardbibliothek definierte oder durch den Benutzer ersetzte Funktion aufrufen. Will ein Compiler hier etwas "besonderes", klassenabhängiges machen (z.B. zwecks Optimierung oder Debuggens), muss dies so geschehen, dass ein konformes Programm keinen Unterschied feststellt. MfG Falk Back to top Allan Rydberg Guest Posted: Fri Sep 22, 2006 2:17 am    Post subject: Re: array aus unterschieldlichen klassen... [snip] argh. ---- wasmanmiteinersimplenfrageallesausloesenkann.... danke fuer all die beitraege! bin nicht wirklich schlauer, dafuer aber desillusionierter. werde mich fuer hardcodete, switch/case routinen entscheiden. sieht dann zwar haesslich aus und gibt viel aufwand bei aenderungen, scheint mir aber noch immer stabiler, als mich auf memory-spielchen mit dem compiler einzulassen... danke! Back to top Heinz Saathoff Guest Posted: Fri Sep 22, 2006 9:11 am    Post subject: Re: array aus unterschiedlichen klassen... Moin, Tibor Pausz schrieb... Quote: Es ist hier wie bei malloc/free. Die Größe des Objektes ist nur bei der Allokation erforderlich, nicht aber bei der Deallokation. Es gibt eine ganze Reihe von Möglichkeiten bei denen es ein Problem darstellt. Denk mal an Placement new. Das aber einen anderen Prototyp hat als der globale operator new(). Die zum placement new gehörende Deallokationsfunktion bekommt auch keine Größenangabe mit. Wenn die Größenangabe erforderlich wäre, wäre ein delete über Zeiger auf Basisobjekt nicht mehr so einfach realisierbar. Irgendwo muß ja die Größe des allokierten Speicherbereichs vermerkt werden. Der Compiler kennt diese Größe zur Compilezeit meist nicht. Quote: Wichtig ist eigentlich nur ein einziges Gegenbeispiel, mehr braucht es doch nicht zu belegen, daß man Probleme bekommen kann, wenn der Destruktor nicht virtuell ist. Ich war ja auch nur der Meinung, daß einige Arten von Klassenableitungen sehr wohl definiertes Verhalten zeigen, auch wenn die Basis keinen virtuellen Destruktor hat. - Heinz Back to top Heinz Saathoff Guest Posted: Fri Sep 22, 2006 12:23 pm    Post subject: Re: array aus unterschieldlichen klassen... Moin, Torsten Robitzki schrieb... Quote: B *_temp_b = operator new(sizeof(B)); _temp_b->B(); A *a = _temp_b; //... // hier ist nur der Basistyp van a statisch bekannt, also // generiert der Compiler a->~A(); // Destruktor von A, wenn ~A nicht virtuell operator delete(a); Es ist hier wie bei malloc/free. Die Größe des Objektes ist nur bei der Allokation erforderlich, nicht aber bei der Deallokation. Wer sagt das? Der Standard?! Immerhin lautet der Prototyp void operator delete(void *); Da gibts keinen Parameter für die Größe. Quote: Wenn dem Compiler die Größe des freizugebenden Speichers bekannt ist, kann er damit Optimierungen vornehmen. Wie denn, wenn er die Standardallokatoren nutzen muß? Immerhin können diese sogar vom Programmierer redefiniert werden. Quote: Allokatoren lassen sich effektiver Implementieren, wenn man die Größe auch beim Freigeben hat. Nur wenn das so vom Standard nicht abgedeckt ist, kann man hier nichts machen. Bei Freigabe von Objekten über Zeiger auf Basis ist die Speichergröße zur Compilezeit sowieso nicht bekannt. Quote: Also, an sizeof(A) != sizeof(B) liegt das undefinierte Verhalten nicht. Das undefinierte Verhalten ist als solches so definiert. Wenn in der Definition der Sprache explizit drin steht, das das Verhalten für diesen oder jehnen Fall nicht definiert ist, ist das Verhalten einfach nicht definiert; nicht mehr, nicht weniger. Soweit die reine Lehre und ACK. Man spart sich dadurch, die Ausnahmen festzulegen, die doch gehen würden. Im Straßenverkehr gibt's ja auch die Regel, nie bei Rot über die Ampel zu fahren. Trotzdem gibt es Fälle, wo das ungefährlich sein kann (rote Fußgängerampel Nachts um 3). Mit dem grünen Pfeil ist sogar eine Ausnahme vom Rotlichtgebot festgelegt worden. Quote: Die Regel könnte dann lauten '... wenn eine der abgeleiteten Klassen eine virtuelle Funktion besitzt, dann muß auch die Basisklasse mindestens eine virtuelle Funktion besitzen'. Es wird sich dann sicher anbieten, den Destruktor virtuell zu machen. Nein, der Destruktor muß virtuell sein, wenn ein Objekt über einen Zeiger gelöscht wird, dessen statischen Typen nicht dem dynamischen Typen des Objekts entspricht. So steht's im Standard! Wenn man sich daran hält, ist man auf der sicheren Seite. - Heinz Back to top Falk Tannhäuser Guest Posted: Fri Sep 22, 2006 1:58 pm    Post subject: Re: array aus unterschieldlichen klassen... Allan Rydberg wrote: Quote: argh. ---- wasmanmiteinersimplenfrageallesausloesenkann.... Das ist die normale Dynamik im Nutznetz - man diskutiert und diskutiert und vergisst dabei mitunter die Ausgangsfrage... Quote: danke fuer all die beitraege! bin nicht wirklich schlauer, dafuer aber desillusionierter. werde mich fuer hardcodete, switch/case routinen entscheiden. sieht dann zwar haesslich aus und gibt viel aufwand bei aenderungen, scheint mir aber noch immer stabiler, als mich auf memory-spielchen mit dem compiler einzulassen... Das geht trotz allem einfacher und hübscher! Polymorphismus wurde im Thread ja schon vorgeschlagen, doch war Deine Schwierigkeit ja wohl, dass die betreffenden Klassen keine gemeinsame Basisklasse besitzen, was zu aufwändig zu ändern sein würde. Für solche Fälle hat die Designpattern-Viererbande das Adapter-Pattern erfunden. Weiterhin können bei hinreichend ähnlicher Implementierung der abgeleiteten Adapterklassen Templates helfen. Das ganze sähe etwa so aus: ____________________________________________________________________ #include <ostream> #include <iostream> #include <cassert> #include <memory> struct class_a { void update() { std::cout << "Aah\n"; } }; struct class_b { void update() { std::cout << "Beh\n"; } }; struct class_c { void update() { std::cout << "Ceh\n"; } }; struct class_d { void update() { std::cout << "Deh\n"; } }; class wrapper_for_update { public: virtual void update() = 0; virtual ~wrapper_for_update() {} }; template<typename T> class wrapper_for_update_impl : public wrapper_for_update { T* ptr; public: wrapper_for_update_impl(T* p) : ptr(p) { assert(ptr != 0); } void update() { ptr->update(); } }; template<typename T> std::auto_ptr<wrapper_for_update> make_wrapper(T* p) { return std::auto_ptr<wrapper_for_update>(new wrapper_for_update_impl<T>(p)); } int main() { class_a* cla = new class_a; class_b* clb = new class_b; class_c* clc = new class_c; class_d* cld = new class_d; { unsigned const MAXCLASSES = 4; std::auto_ptr<wrapper_for_update> myClaArr[MAXCLASSES]; myClaArr[0] = make_wrapper(cla); myClaArr[1] = make_wrapper(clb); myClaArr[2] = make_wrapper(clc); myClaArr[3] = make_wrapper(cld); for(unsigned i = 0; i < MAXCLASSES; ++i) myClaArr[i]->update(); } delete cld; delete clc; delete clb; delete cla; return 0; } ____________________________________________________________________ Hier habe ich zwecks Vereinfachung des Aufräumens std::auto_ptr verwendet. Natürlich würde das nicht mehr funktionieren, sobald man statt des Arrays für 'myClaArr' einen Standard-Container nehmen möchte. Alternativen wären normale Zeiger 'wrapper_for_update*' (die man dann natürlich von Hand deleten muss) oder boost::shared_ptr. In jedem Fall muss man auch darauf achten, dass die Ursprungsobjekte noch leben, wenn ihr update() aufgerufen wird - also am besten dafür sorgen, das die Wrapper (im Beispiel in 'myClaArr') vor dem Deleten von 'cla' bis 'cld' verschwinden. Noch ein Hinweis: Sollten einige der Ursprungsklassen Sonderbehandlung beim update() benötigen, kann man dies durch passende Spezialisierung von 'wrapper_for_update_impl' erreichen. MfG Falk Back to top Tibor Pausz Guest Posted: Fri Sep 22, 2006 2:40 pm    Post subject: Re: array aus unterschiedlichen klassen... Heinz Saathoff schrieb: Quote: Ich war ja auch nur der Meinung, daß einige Arten von Klassenableitungen sehr wohl definiertes Verhalten zeigen, auch wenn die Basis keinen virtuellen Destruktor hat. Da liegt ja Dein Verständnisproblem, es ist so, daß einige Implementationen sich so verhalten wie von Dir erwartet, es gibt aber keinerlei Garantie, daß dies alle so tun, oder die von Dir benutzen dies noch in Zukunft tun werden. Ergo verlaß Dich nur auf das was _garantiert_ ist und nicht auf Spekulationen. Back to top Bob Hairgrove Guest Posted: Fri Sep 22, 2006 8:04 pm    Post subject: Re: array aus unterschieldlichen klassen... On Thu, 21 Sep 2006 23:17:50 +0200, Allan Rydberg <alrdbg (AT) resalehost (DOT) networksolutions.com> wrote: Quote: werde mich fuer hardcodete, switch/case routinen entscheiden. sieht dann zwar haesslich aus und gibt viel aufwand bei aenderungen, scheint mir aber noch immer stabiler, als mich auf memory-spielchen mit dem compiler einzulassen... Wenn man sich einfach an die Regeln hält, die im C++-Standard stehen, gibt es keine "memory-Spielchen" mehr. -- Bob Hairgrove NoSpamPlease (AT) Home (DOT) com Back to top        C++Talk.NET Forum Index -> C++ (German) All times are GMT Goto page Previous  1, 2, 3, 4  Next Page 3 of 4 Powered by phpBB © 2001, 2006 phpBB Group