This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc visibility used by moz

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
| ), 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]