Joe Buck <[EMAIL PROTECTED]> writes: | On Sat, Jul 15, 2006 at 01:03:46AM +0200, Gabriel Dos Reis wrote: | > Joe Buck <[EMAIL PROTECTED]> writes: | > | > | On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote: | > | > On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before() | > | > is defined in terms of the mangled names of the types. I'm unable to | > | > find the mangled names are different. | > | | > | Which is why we should just say that it is unspecified behavior to | > | compare typeinfo objects in this case. | > | > What that concretely means is that it alienates, for example, codes | > based on Factory desigbn pattern using typeinfo objects. | | No, it doesn't. And I was doing pretty much exactly what you are talking | about back in 1992 (as part of what is now called Ptolemy Classic, see | http://ptolemy.eecs.berkeley.edu/ptolemyclassic/ ), adding new object code | to running executables to define new classes, with a Factory pattern | interface, long before we had typeinfo or the concept of design patterns | was introduced.
Yes, people were programming with classes in C long before they switched to C++. No offense, intended. | It only means that you can't do the job with typeinfo | comparison alone. Since we didn't have typeinfo then, the classes had | to have a common base to implement the necessary support for type | identification, registration with the factory, and cloning. | | To stay in the realm of defined behavior, you only need to avoid the | case where two distinct classes have the same name, because that's the | case where the typeinfo comparison's behavior is implementation-dependent. | This is easily done. -- Gaby
