gcc visibility used by moz

Gabriel Dos Reis gdr@integrable-solutions.net
Fri Jul 14 23:23:00 GMT 2006


Mike Stump <mrs@apple.com> writes:

| On Jul 14, 2006, at 4:03 PM, Gabriel Dos Reis wrote:
| > What that concretely means is that it alienates, for example, codes
| > based on Factory desigbn pattern using typeinfo objects.
| 
| I'd love some input from the MS VC++ programming crowd on this  issue.

yes, that will be helfpul.  

If I understand correctly, MS VC++ does not use the mangle name, so it
would be interesting to hear how they implement operator== and
before() for type_infos.

| I don't see how they get past this issue.  I've had some  claim, but
| it's a feature, not a bug.
| 
| The basic question is, are two unrelated types in different dlls the
| same, just because they have the same name?  How do you prevent them
| from being the same?

it has been a kind of implicit garantee that two classes with external
linkage and with same mangled names refers to the same type.
Implementations have used that property -- which "leaks" into user
codes via type_info::operator== and type_info::before. 

My primary concern is to what extent that guarantee continues to hold
with the visibility stuff and without alienating coding patterns.  

When __GXX_MERGED_TYPEINFO_NAMES is defined, there is no problem as
things get separate addresses and comparisons are done on addresses.
Your earlier suggestion to discontinue support for
!__GXX_MERGED_TYPEINFO_NAMES may be a way out, unless a scheme
outlined by Geoff is implemented (that seems unlikely, as it is
complicated). 

-- Gaby



More information about the Gcc mailing list