Re: gcc visibility used by moz

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Joe Buck <Joe.Buck@synopsys.COM> writes:

| On Sat, Jul 15, 2006 at 01:03:46AM +0200, Gabriel Dos Reis wrote:
| > Joe Buck <Joe.Buck@synopsys.COM> 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