C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  RTTI mixed mit non-RTTI Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ (German) View previous topic :: View next topic   Author Message Albrecht Fritzsche Guest Posted: Wed Feb 02, 2005 11:49 pm    Post subject: RTTI mixed mit non-RTTI Hallo, welche Implikationen koennen sich denn ergeben, wenn Teile des Programms mit RTTI-Support, andere hinwiederrum ohne RTTI erzeugt wurden? Ein vorstellbares Szenario waere fuer mich, dass RTTI-Code Objekte aus dem Nicht-RTTI-Code verwendet und zB deren typeid abfragen will. Ok, mit dieser Einschraenkung koennte ich uU leben. Aber ist denn die Verwendung von im RTTI-Code implementierter Objekte innerhalb von Nicht-RTTI-Code /immer/ sicher? Wenn nicht, was koennte denn da schief gehen? Oder genauer - wenn keinerlei RTTI-Features verwendet werden, dann kann RTTI- und Nicht-RTTI-Code frei gemischt werden? Wenn nicht, warum nicht? BTW, wie ist denn RTTI-Support implementiert? Ist denn zB ein Pointer auf die zugehoerige type_info vor der vtable ueblich fuer polymorphe Typen? Danke fuer jeden Hinweis oder Tip 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 Marcel Müller Guest Posted: Thu Feb 03, 2005 8:28 am    Post subject: Re: RTTI mixed mit non-RTTI Albrecht Fritzsche wrote: Quote: welche Implikationen koennen sich denn ergeben, wenn Teile des Programms mit RTTI-Support, andere hinwiederrum ohne RTTI erzeugt wurden? Ein vorstellbares Szenario waere fuer mich, dass RTTI-Code Objekte aus dem Nicht-RTTI-Code verwendet und zB deren typeid abfragen will. Ok, mit dieser Einschraenkung koennte ich uU leben. Aber ist denn die Verwendung von im RTTI-Code implementierter Objekte innerhalb von Nicht-RTTI-Code /immer/ sicher? Wenn nicht, was koennte denn da schief gehen? Oder genauer - wenn keinerlei RTTI-Features verwendet werden, dann kann RTTI- und Nicht-RTTI-Code frei gemischt werden? Wenn nicht, warum nicht? BTW, wie ist denn RTTI-Support implementiert? Ist denn zB ein Pointer auf die zugehoerige type_info vor der vtable ueblich fuer polymorphe Typen? Das sind alles Fragen, die /nur/ der entsprechende Compilerbauer beantworten kann. Und da sich nicht der geringste Hinweis auf einen Compiler in dem Posting findet, wird auch niemand Erfahrungswerte beisteuern können. Ein standardkonformer C++-Compiler unterstützt RTTI. Da stellt sich die Frage eigentlich nicht. Nebenbei bemerkt fallen mir etliche Gründe ein, warum man mit soetwas nicht experimentieren sollte. - Das /kann/ ganz subtile Programmfehler geben, die extrem selten auftreten. - Das /kann/ heute funktionieren, mit der nächsten Compilerrealease aber nicht mehr. - Das /kann/ davon abhängen, in welcher Reihenfolge die Module und damit die Runtime initialisiert werden. - ... Solange es keine standardisierten Wege gibt, C++ Metadaten in den executables abzulegen, sollte ein C++-Projekt immer als ganzes mit konsistenten Compilereinstellungen übersetzt werden. Das führt natürlich im Kontext C++ Shared Libraries zu Problemen, diese können eigentlich nicht projektübergreifend genutzt werden. Java und .NET haben dieses Problem gelöst. Für C++ steht das noch aus. Marcel -- 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 Olaf Krzikalla Guest Posted: Thu Feb 03, 2005 10:14 am    Post subject: Re: RTTI mixed mit non-RTTI Hi, Albrecht Fritzsche schrieb: Quote: welche Implikationen koennen sich denn ergeben, wenn Teile des Programms mit RTTI-Support, andere hinwiederrum ohne RTTI erzeugt wurden? Problematisch ist, dass der Standard keine Aussagen über das Ein-/Ausschalten von RTTI macht - er geht davon aus, dass RTTI immer angeschaltet ist (zumindest habe ich auf die Schnelle keine gegenteiligen Aussagen gefunden). Quote: BTW, wie ist denn RTTI-Support implementiert? Ist denn zB ein Pointer auf die zugehoerige type_info vor der vtable ueblich fuer polymorphe Typen? Das wäre der vernünftige Weg, der dann auch keine Probleme beim Mischen macht. K.A., ob das alle Compiler so machen. Der naive Weg wäre eher, den Pointer an den physischen Anfang der vtable (statt hinter das RTTI-Tag) zeigen zu lassen und am Anfang der vtable steht erstmal das RTTI-Tag. Wenn dann einige Code-Teile den Offset für ein RTTI-Tag bei der Ermittlung einer virtuellen Funktion beachten und andere Teile das nicht tun, sieht es düster aus. Das kannst Du eigentlich nur ausprobieren oder der Compiler-Doku entnehmen. MfG Olaf Krzikalla -- 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: Thu Feb 03, 2005 6:17 pm    Post subject: Re: RTTI mixed mit non-RTTI Marcel Müller wrote: Quote: Das sind alles Fragen, die /nur/ der entsprechende Compilerbauer beantworten kann. Und da sich nicht der geringste Hinweis auf einen Compiler in dem Posting findet, wird auch niemand Erfahrungswerte beisteuern können. Kluge Antwort Das Problem ist, dass bei meinem Arbeitgeber (mental images) wir uns auch nicht auf ein paar Plattformen beschraenken koennen, sondern leicht ein paar dutzend Compiler (verschiedene gcc's incl.) korrekten Code erzeugen muessen. Mir wuerde ja Erfahrungen mit jedem beliebigen modernen Compiler weiter- helfen - daher die allgemeine Frage. Quote: Ein standardkonformer C++-Compiler unterstützt RTTI. Da stellt sich die Frage eigentlich nicht. Doch - genau dann, wenn Du dieses Feature abschalten willst, da es (uU) unnuetz Code erzeugt. Wenn Du auf Exceptions + dynamic_cast + type_info verzichten kannst, warum sollte man dann RTTI unterstuetzen? Quote: Nebenbei bemerkt fallen mir etliche Gründe ein, warum man mit soetwas nicht experimentieren sollte. Alles richtig - aber vielleicht ist es ja so, dass RTTI- und Nicht-RTTI- Code wunderbar miteinander laufen bzw. nie miteinander laufen. Auf solch grundsaetzliche Erfahrung zielte meine Frage ab. 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 Olaf Krzikalla Guest Posted: Fri Feb 04, 2005 11:10 am    Post subject: Re: RTTI mixed mit non-RTTI Hi, Albrecht Fritzsche schrieb: Quote: mental images [snip] Doch - genau dann, wenn Du dieses Feature abschalten willst, Wodurch der Compiler nicht mehr standardkonform wäre. Quote: da es (uU) unnuetz Code erzeugt. Wenn Du auf Exceptions + dynamic_cast + type_info verzichten kannst, warum sollte man dann RTTI unterstuetzen? Hab Eure Webseite mal angeschaut und da stellt sich mir dann doch die Frage, ob es denn in Eurer Umgebung soo wichtig ist, ein klein wenig evtl. unnützen Code mitzuschleppen? Exceptions haben im übrigen nichts mit RTTI zu tun. (BTW: Ihr habt interessante Jobangebote ;-) MfG Olaf Krzikalla -- 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: Fri Feb 04, 2005 11:42 am    Post subject: Re: RTTI mixed mit non-RTTI Albrecht Fritzsche wrote: Quote: Ein standardkonformer C++-Compiler unterstützt RTTI. Da stellt sich die Frage eigentlich nicht. Doch - genau dann, wenn Du dieses Feature abschalten willst, Wenn du es abschaltest, ist der Compiler nicht mehr konform. Quote: da es (uU) unnuetz Code erzeugt. Tut es das, oder glaubst du nur, daß es das tut? Wieviel größer/langsamer/wasauchimmer wird dein Code, wenn du RTTI einschaltest? Quote: Wenn Du auf Exceptions Exceptions haben nichts mit RTTI zu tun. Quote: + dynamic_cast + type_info verzichten kannst, warum sollte man dann RTTI unterstuetzen? Gegenfrage: Wenn das Abschalten zu potenziellen Problemen führt, warum sollte man RTTI nicht einfach eingeschaltet lassen? Quote: Nebenbei bemerkt fallen mir etliche Gründe ein, warum man mit soetwas nicht experimentieren sollte. Alles richtig - aber vielleicht ist es ja so, dass RTTI- und Nicht-RTTI- Code wunderbar miteinander laufen bzw. nie miteinander laufen. Auf solch grundsaetzliche Erfahrung zielte meine Frage ab. Wenn du dich dabei auf einen einzigen Compiler beziehen würdest, gäbe es auf diese Frage eine eindeutige Antwort. Aber allgemein kann man nichts dazu sagen, außer, daß man sich nicht darauf verlassen kann, daß es geht. -- 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: Fri Feb 04, 2005 3:27 pm    Post subject: Re: RTTI mixed mit non-RTTI "Albrecht Fritzsche" <alis-news (AT) gmx (DOT) net> schrieb im Newsbeitrag news:36f84iF4tjvshU1 (AT) individual (DOT) net... Quote: Marcel Müller wrote: Das sind alles Fragen, die /nur/ der entsprechende Compilerbauer beantworten kann. Und da sich nicht der geringste Hinweis auf einen Compiler in dem Posting findet, wird auch niemand Erfahrungswerte beisteuern können. Kluge Antwort Das Problem ist, dass bei meinem Arbeitgeber (mental images) wir uns auch nicht auf ein paar Plattformen beschraenken koennen, sondern leicht ein paar dutzend Compiler (verschiedene gcc's incl.) korrekten Code erzeugen muessen. Tja, je mehr Compiler, desto schlechter stehen die generellen Chancen. Quote: Mir wuerde ja Erfahrungen mit jedem beliebigen modernen Compiler weiter- helfen - daher die allgemeine Frage. Ein standardkonformer C++-Compiler unterstützt RTTI. Da stellt sich die Frage eigentlich nicht. Doch - genau dann, wenn Du dieses Feature abschalten willst, da es (uU) unnuetz Code erzeugt. Wenn Du auf Exceptions + dynamic_cast + type_info verzichten kannst, warum sollte man dann RTTI unterstuetzen? Nebenbei bemerkt fallen mir etliche Gründe ein, warum man mit soetwas nicht experimentieren sollte. Alles richtig - aber vielleicht ist es ja so, dass RTTI- und Nicht-RTTI- Code wunderbar miteinander laufen bzw. nie miteinander laufen. Auf solch grundsaetzliche Erfahrung zielte meine Frage ab. Rein formall ist es dann nicht mehr C++, und wenn doch, verletzt Du die ODR. Kann sein, daß es bei Deinen Compilern nichts ausmacht - daß mußt Du aber mit den Herstellern kontrollieren. Ich habe einen kleinen Test durchgeführt: Einmal 100, einmal 1000 Klassenpaare (Basis <-> Abgeleitet). Codegrößenunterschied war jeweils im Breich von 6% - aber das Programm hat sonst überhaupt nichts gemacht. In einem echten Programm erwarte ich keinen signifikanten Unterschied zwischen RTII ein oder aus - abgesehen davon, daß man dann auf der sicheren Seite ist .. Die Entscheidung obliegt Dir. 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 Albrecht Fritzsche Guest Posted: Fri Feb 04, 2005 7:16 pm    Post subject: Re: RTTI mixed mit non-RTTI Rolf Magnus wrote: Quote: Albrecht Fritzsche wrote: Ein standardkonformer C++-Compiler unterstützt RTTI. Da stellt sich die Frage eigentlich nicht. Doch - genau dann, wenn Du dieses Feature abschalten willst, Wenn du es abschaltest, ist der Compiler nicht mehr konform. Wie gesagt - ich weiss und ich stelle diese Frage doch auch eher mit einem pragmatischen als mit einem akademischen Hintergrund. Quote: da es (uU) unnuetz Code erzeugt. Tut es das, oder glaubst du nur, daß es das tut? ;-) EH vergroessert den Code um bis zu ~15% und verlangsamt ihn um bis zu ~6%, wenn man Lippmans "C++ Object Model"-Buch noch zur Hilfe nehmen darf (ist nicht mehr wirklich aktuell, but anyway). Und, falls Du denkst, dass dies nicht signifikant ist - doch, in manchen Faellen ist es das. Quote: Wenn Du auf Exceptions Exceptions haben nichts mit RTTI zu tun. Hm, wie wird dann aber zur Laufzeit eine Exception vom Exception Handler der passenden catch-Klausel zugeordnet? Lippman schreibt "RTTI is a necessary side effect of support for EH." Undwenn ich mal die Itanium C++ ABI zitieren darf "2.9 Run-Time Type Information (RTTI) 2.9.1 General The C++ programming language definition implies that information about types be available at run time for three distinct purposes: 1. to support the typeid operator, 2. to match an exception handler with a thrown object, and 3. to implement the dynamic_cast operator." Wieso denkst Du, dass die nichts miteinander zu tun haben?? Quote: + dynamic_cast + type_info verzichten kannst, warum sollte man dann RTTI unterstuetzen? Gegenfrage: Wenn das Abschalten zu potenziellen Problemen führt, warum sollte man RTTI nicht einfach eingeschaltet lassen? Code Size and Runtime Optimierung - es geht hier ja nicht um Web Services ;-) Quote: Wenn du dich dabei auf einen einzigen Compiler beziehen würdest, gäbe es auf diese Frage eine eindeutige Antwort. Aber allgemein kann man nichts dazu sagen, außer, daß man sich nicht darauf verlassen kann, daß es geht. Ich war also noch immer nicht klar genug? Sorry. Nenne einen einzigen (heutzutagigen) Compiler, wo das determiistisch Probleme bereitet, und ich bin zufrieden - ob gcc 3.x, Vis C++ 7.1, die neuen Intel- or MIPSpro Compiler, ganz egal. 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 Albrecht Fritzsche Guest Posted: Fri Feb 04, 2005 7:29 pm    Post subject: Re: RTTI mixed mit non-RTTI Olaf Krzikalla wrote: Quote: Albrecht Fritzsche schrieb: Doch - genau dann, wenn Du dieses Feature abschalten willst, Wodurch der Compiler nicht mehr standardkonform wäre. Ja, wie gesagt richtig, aber fuer mich im Moment nicht hinreichend. Ich habe ja zB auch das "continous memory" eines std::vectors verwendet, als es noch nicht im korrigierten Standard zu finden war - ich weiss, dass da die Sachlage "etwas" war, ich meine aber den Pragmatismus. Zudem wuerde dies ja heissen, dass saemtliche C++-Libraries RTTI angeschaltet haben muessen - ich glaube dies nicht und vermute halt daher, dass dies nicht per se zu Crashes fuehren muss. Aber nun les' ich erstmal weiter ueber mgl. Implementierungen... Quote: Hab Eure Webseite mal angeschaut und da stellt sich mir dann doch die Frage, ob es denn in Eurer Umgebung soo wichtig ist, ein klein wenig evtl. unnützen Code mitzuschleppen? Vielleicht nicht lang genug angeguckt Mal ein kleines Bsp - fuer "Matrix2/3" hat das Rendern eines(!) Bilds auf einem Doppel-Prozessor- Rechners (ja, der hatte hinreichend Speicher, ...) ca 30 h gedauert. Wenn da der Code noch etwas besser cachen koennte, dann? Oder wenn da der Code ohne EH ca 10% schneller laeuft? Quote: Exceptions haben im übrigen nichts mit RTTI zu tun. Ich glaube, dies stimmt so nicht - siehe meine Erwiederung an Rolf Magnus. Ali Quote: (BTW: Ihr habt interessante Jobangebote Sogar interessante Jobs -- 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: Fri Feb 04, 2005 7:31 pm    Post subject: Re: RTTI mixed mit non-RTTI "Albrecht Fritzsche" <alis-news (AT) gmx (DOT) net> schrieb im Newsbeitrag news:36hvvmF53j6qgU1 (AT) individual (DOT) net... Quote: Rolf Magnus wrote: Albrecht Fritzsche wrote: Ein standardkonformer C++-Compiler unterstützt RTTI. Da stellt sich die Frage eigentlich nicht. Doch - genau dann, wenn Du dieses Feature abschalten willst, Wenn du es abschaltest, ist der Compiler nicht mehr konform. Wie gesagt - ich weiss und ich stelle diese Frage doch auch eher mit einem pragmatischen als mit einem akademischen Hintergrund. da es (uU) unnuetz Code erzeugt. Tut es das, oder glaubst du nur, daß es das tut? ;-) EH vergroessert den Code um bis zu ~15% und verlangsamt ihn um bis zu ~6%, wenn man Lippmans "C++ Object Model"-Buch noch zur Hilfe nehmen darf (ist nicht mehr wirklich aktuell, but anyway). Und, falls Du denkst, dass dies nicht signifikant ist - doch, in manchen Faellen ist es das. Wenn Du auf Exceptions Exceptions haben nichts mit RTTI zu tun. Hm, wie wird dann aber zur Laufzeit eine Exception vom Exception Handler der passenden catch-Klausel zugeordnet? Lippman schreibt "RTTI is a necessary side effect of support for EH." Undwenn ich mal die Itanium C++ ABI zitieren darf "2.9 Run-Time Type Information (RTTI) 2.9.1 General The C++ programming language definition implies that information about types be available at run time for three distinct purposes: 1. to support the typeid operator, 2. to match an exception handler with a thrown object, and 3. to implement the dynamic_cast operator." Wieso denkst Du, dass die nichts miteinander zu tun haben?? Weil sie orthogonal sind, nur halt kombiniert verwendet werden _können_, da beide Teil von C++ sind. Beim Werfen einer Exception wird die kopiert, also findet z.B. slicing statt, der dynamische Type geht hier verloren. Da kann der Compiler zusammen mit dem exception-Objekt irgendwo in irgendeiner Form den Typ der Exception sichern, z.B. in Form eines einfachen Strings, oder enums..... Beim Fangen der exception kann dann diese Information abgeglichen werden mit den catch-handlern. 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 Albrecht Fritzsche Guest Posted: Fri Feb 04, 2005 8:24 pm    Post subject: Re: RTTI mixed mit non-RTTI Thomas Mang wrote: Quote: "Albrecht Fritzsche" <alis-news (AT) gmx (DOT) net> schrieb im Newsbeitrag Wieso denkst Du, dass die nichts miteinander zu tun haben?? Weil sie orthogonal sind, nur halt kombiniert verwendet werden _können_, da beide Teil von C++ sind. Beim Werfen einer Exception wird die kopiert, also findet z.B. slicing statt, der dynamische Type geht hier verloren. Generell? Das darf, glaube ich, nicht sein, denn dann wuerde ja Code wie der folgende nicht funktionieren struct Base { virtual ~Base(){} virtual void print() const = 0; }; struct D : public Base { void print() const { cout << "D"; } }; int main() { try { throw D(); } catch (const Base& base) { base.print(); } oder? Quote: Da kann der Compiler zusammen mit dem exception-Objekt irgendwo in irgendeiner Form den Typ der Exception sichern, z.B. in Form eines einfachen Strings, oder enums..... Beim Fangen der exception kann dann diese Information abgeglichen werden mit den catch-handlern. Ja, natuerlich bietet sich da doch gleich RTTI an, oder? Ich habe gerade folgende interessante Notiz gefunden - da etwas laenger, haengt sie unten dran, ist wohl auch schon etwas aelter, aber egal, ich versuche nun halt ersteinmal mgl Implementierungen zu verstehen Ali Exception Handling ================== Note, exception handling in g++ is still under development. This section describes the mapping of C++ exceptions in the C++ front-end, into the back-end exception handling framework. The basic mechanism of exception handling in the back-end is unwind-protect a la elisp. This is a general, robust, and language independent representation for exceptions. The C++ front-end exceptions are mapping into the unwind-protect semantics by the C++ front-end. The mapping is describe below. When -frtti is used, rtti is used to do exception object type checking, when it isn't used, the encoded name for the type of the object being thrown is used instead. All code that originates exceptions, even code that throws exceptions as a side effect, like dynamic casting, and all code that catches exceptions must be compiled with either -frtti, or -fno-rtti. It is not possible to mix rtti base exception handling objects with code that doesn't use rtti. The exceptions to this, are code that doesn't catch or throw exceptions, catch (...), and code that just rethrows an exception. Currently we use the normal mangling used in building functions names (int's are "i", const char * is PCc) to build the non-rtti base type descriptors for exception handling. These descriptors are just plain NULL terminated strings, and internally they are passed around as char *. -- 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: Fri Feb 04, 2005 11:16 pm    Post subject: Re: RTTI mixed mit non-RTTI Albrecht Fritzsche wrote: Quote: da es (uU) unnuetz Code erzeugt. Tut es das, oder glaubst du nur, daß es das tut? ;-) EH vergroessert den Code um bis zu ~15% und verlangsamt ihn um bis zu ~6%, wenn man Lippmans "C++ Object Model"-Buch noch zur Hilfe nehmen darf (ist nicht mehr wirklich aktuell, but anyway). Und, falls Du denkst, dass dies nicht signifikant ist - doch, in manchen Faellen ist es das. Ist EH Exception-Handling? Wir sprachen doch nur über RTTI. Wenn dir Exception-Handling zu viel Overhead hat, schalt Exception-Handling aus, nicht RTTI. Quote: Wenn Du auf Exceptions Exceptions haben nichts mit RTTI zu tun. Hm, wie wird dann aber zur Laufzeit eine Exception vom Exception Handler der passenden catch-Klausel zugeordnet? Das weiß ich nicht genau. Quote: Lippman schreibt "RTTI is a necessary side effect of support for EH." Undwenn ich mal die Itanium C++ ABI zitieren darf "2.9 Run-Time Type Information (RTTI) 2.9.1 General The C++ programming language definition implies that information about types be available at run time for three distinct purposes: 1. to support the typeid operator, 2. to match an exception handler with a thrown object, and 3. to implement the dynamic_cast operator." Wieso denkst Du, dass die nichts miteinander zu tun haben?? RTTI reicht dafür auf jeden Fall nicht aus, denn RTTI funktioniert nur für polymorphe Klassen und nur innerhalb einer Klassenhierarchie. Ich kann aber alles werfen und fangen, was auch kopiert werden kann, also auch nicht-polymorphe Klassen, Klassen aus mehreren unabhängigen Hierarchien und sogar eingebaute Typen. Abgesehen davon funktioniert z.b. bei g++ Exception-Handling auch bei ausgeschaltetem RTTI. Quote: + dynamic_cast + type_info verzichten kannst, warum sollte man dann RTTI unterstuetzen? Gegenfrage: Wenn das Abschalten zu potenziellen Problemen führt, warum sollte man RTTI nicht einfach eingeschaltet lassen? Code Size and Runtime Optimierung - es geht hier ja nicht um Web Services Allerdings steht immer noch aus, ob RTTI hier wirklich einen signifikanten Unterschied macht. Quote: Wenn du dich dabei auf einen einzigen Compiler beziehen würdest, gäbe es auf diese Frage eine eindeutige Antwort. Aber allgemein kann man nichts dazu sagen, außer, daß man sich nicht darauf verlassen kann, daß es geht. Ich war also noch immer nicht klar genug? Sorry. Nenne einen einzigen (heutzutagigen) Compiler, wo das determiistisch Probleme bereitet, und ich bin zufrieden - ob gcc 3.x, Vis C++ 7.1, die neuen Intel- or MIPSpro Compiler, ganz egal. Vielleicht war es ich, der sich nicht klar genug ausgedrückt hat. Ich finde, du solltest eher andersrum vorgehen, also nur abschalten, wenn das nachweislich nicht zu Fehlern führt. -- 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: Sat Feb 05, 2005 1:05 am    Post subject: Re: RTTI mixed mit non-RTTI Albrecht Fritzsche wrote: Quote: Olaf Krzikalla wrote: Albrecht Fritzsche schrieb: Doch - genau dann, wenn Du dieses Feature abschalten willst, Wodurch der Compiler nicht mehr standardkonform wäre. Ja, wie gesagt richtig, aber fuer mich im Moment nicht hinreichend. Ich habe ja zB auch das "continous memory" eines std::vectors verwendet, als es noch nicht im korrigierten Standard zu finden war - ich weiss, dass da die Sachlage "etwas" war, ich meine aber den Pragmatismus. Zudem wuerde dies ja heissen, dass saemtliche C++-Libraries RTTI angeschaltet haben muessen Nein, es heißt nur, daß die Norm nicht definiert, was passiert, wenn man RTTI ausschaltet, weil es soetwas dort gar nicht gibt. Quote: - ich glaube dies nicht und vermute halt daher, dass dies nicht per se zu Crashes fuehren muss. Aber nun les' ich erstmal weiter ueber mgl. Implementierungen... Hab Eure Webseite mal angeschaut und da stellt sich mir dann doch die Frage, ob es denn in Eurer Umgebung soo wichtig ist, ein klein wenig evtl. unnützen Code mitzuschleppen? Vielleicht nicht lang genug angeguckt Mal ein kleines Bsp - fuer "Matrix2/3" hat das Rendern eines(!) Bilds auf einem Doppel-Prozessor- Rechners (ja, der hatte hinreichend Speicher, ...) ca 30 h gedauert. Wenn da der Code noch etwas besser cachen koennte, dann? Oder wenn da der Code ohne EH ca 10% schneller laeuft? Was, wenn es nach 29 Stunden abstürzt, weil irgendwo ganz unten im Bild ein Objekt ist, für das eine bisher noch nicht verwendete Funktion benötigt wird, die aufgrund von ausgeschaltetem RTTI nicht richtig arbeitet? Nicht nur, daß das Bild dann kaputt ist, sondern das Rendern muß auch noch angehalten werden, bis das Programm repariert ist. Korrektheit ist wichtiger als Geschwindigkeit. -- 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: Sat Feb 05, 2005 1:08 am    Post subject: Re: RTTI mixed mit non-RTTI "Albrecht Fritzsche" <alis-news (AT) gmx (DOT) net> schrieb im Newsbeitrag news:36i3uoF525v0mU1 (AT) individual (DOT) net... Quote: Thomas Mang wrote: "Albrecht Fritzsche" <alis-news (AT) gmx (DOT) net> schrieb im Newsbeitrag Wieso denkst Du, dass die nichts miteinander zu tun haben?? Weil sie orthogonal sind, nur halt kombiniert verwendet werden _können_, da beide Teil von C++ sind. Beim Werfen einer Exception wird die kopiert, also findet z.B. slicing statt, der dynamische Type geht hier verloren. Generell? Das darf, glaube ich, nicht sein, denn dann wuerde ja Code wie der folgende nicht funktionieren struct Base { virtual ~Base(){} virtual void print() const = 0; }; struct D : public Base { void print() const { cout << "D"; } }; int main() { try { throw D(); } catch (const Base& base) { base.print(); } Hier ist der statische Typ der throw-expression ein D, also wird auch ein D geworfen. Hingegen: #include #include <ostream> struct base { virtual ~base(){} virtual char const* what() const {return "base";} }; struct derived : base { virtual char const* what() const {return "derived";} }; void bar(base const& B) { throw B; } int main(int, char*[]) { derived D; try{ bar(D); } catch (derived const& D) { std::cout << "Derived catchednType of object: " << D.what(); } catch(base const & B) { std::cout << "Base catchednType of object: " << B.what(); } } Hier ist der statische Typ der throw-expression ein base, auch wenn der dynamische Typ ein derived ist. Der dynamische Typ spielt hier jedoch keine Rolle; der derived-Anteil geht über slicing verloren, und es wird ein base-Objekt geworfen. Quote: oder? Da kann der Compiler zusammen mit dem exception-Objekt irgendwo in irgendeiner Form den Typ der Exception sichern, z.B. in Form eines einfachen Strings, oder enums..... Beim Fangen der exception kann dann diese Information abgeglichen werden mit den catch-handlern. Ja, natuerlich bietet sich da doch gleich RTTI an, oder? Zum Beispiel. Muß ist es aber nicht. Vielleicht macht es jeder Compiler über RTTI, vielleicht keiner, vielleicht ein paar, vielleicht kann man es über Optionen einstellen. Ehrlich gesagt, ich weiß es nicht. Ich habe gerade Quote: folgende interessante Notiz gefunden - da etwas laenger, haengt sie unten dran, ist wohl auch schon etwas aelter, aber egal, ich versuche nun halt ersteinmal mgl Implementierungen zu verstehen Ali Exception Handling ================== Note, exception handling in g++ is still under development. This section describes the mapping of C++ exceptions in the C++ front-end, into the back-end exception handling framework. The basic mechanism of exception handling in the back-end is unwind-protect a la elisp. This is a general, robust, and language independent representation for exceptions. The C++ front-end exceptions are mapping into the unwind-protect semantics by the C++ front-end. The mapping is describe below. When -frtti is used, rtti is used to do exception object type checking, when it isn't used, the encoded name for the type of the object being thrown is used instead. All code that originates exceptions, even code that throws exceptions as a side effect, like dynamic casting, and all code that catches exceptions must be compiled with either -frtti, or -fno-rtti. It is not possible to mix rtti base exception handling objects with code that doesn't use rtti. The exceptions to this, are code that doesn't catch or throw exceptions, catch (...), and code that just rethrows an exception. Currently we use the normal mangling used in building functions names (int's are "i", const char * is PCc) to build the non-rtti base type descriptors for exception handling. These descriptors are just plain NULL terminated strings, and internally they are passed around as char *. Tja, das liest sich nach einem Compiler, der abhängig von Optionen einmal RTTI für's identifizieren des exception-Objektes verwendet, und einmal einen anderen Mechanismus. Beides ist vollkommen legal. Ich zeige Verständnis dafür, wenn Du meinst, exceptions blähen den Code auf. Allerdings verzichtest Du somit auf vieles in der Standardbibliothek (wie verhält sich eigentlich bei Dir vector, wenn exceptions deaktiviert sind, und beim Speicheralloziieren oder Kopieren der Objekte nach Wachsen eine exception auftritt?) oder anderen Bibliotheken. Bei RTTI bin ich hingegen skeptischer. Ich erwarte, daß dieser Mechanismus nicht mehr macht als ein paar Einträge in die vtble-Liste hinzuzufügen - und das nur pro Klasse, logischerweise. Hast Du mal gemessen, ob RTTI ein/aus bei einem echten Programm wirklich einen nennenswerten Unterschied macht? [Ich weiß schon, jedes byte mehr kann eine page-fault auslösen etc. oder virtuellen Speicher benötigen...] 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 Albrecht Fritzsche Guest Posted: Sat Feb 05, 2005 1:44 am    Post subject: Re: RTTI mixed mit non-RTTI Rolf Magnus wrote: Quote: Albrecht Fritzsche wrote: Ist EH Exception-Handling? Wir sprachen doch nur über RTTI. Wenn dir Exception-Handling zu viel Overhead hat, schalt Exception-Handling aus, nicht RTTI. Nun, bei RTTI kommt ja wenigstens ein Pointer pro Klasse (fuer die entsprechende type_info) hinzu. Quote: Vielleicht war es ich, der sich nicht klar genug ausgedrückt hat. Ich finde, du solltest eher andersrum vorgehen, also nur abschalten, wenn das nachweislich nicht zu Fehlern führt. Ja, und daher genau meine Frage - wann und wie fuehrt dies nachweislich zu Fehlern? Auf allen gcc 3.x, Vis C++ 7.1, MipsPro, etc... funktionieren primitive Bsp mit mixed Code, sonst haette ich die Frage auch garnicht gestellt. Das Problem ist doch, das ich von funktionierenden Bsp halt nicht auf die Allgemeingueltigkeit schliessen kann, andersherum *ein* nicht- funktionierendes Bsp, das jemand aufzeigen kann, den ganzen Versuch, solchen Code zu mischen, ueber den Haufen werfen wuerde. Nur, dieses Bsp hat noch niemand hier erbracht - und vielleicht auch daher, weil solcher Code vielleicht doch miteinander gemischt werden kann? 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 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, 3  Next Page 1 of 3   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.