This is the mail archive of the gcc@gcc.gnu.org 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


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.  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.


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