First of all, thank you for "seeing" the problem I was trying to communicate.
Geoffrey Keating <[EMAIL PROTECTED]> writes: | Joe Buck <[EMAIL PROTECTED]> writes: | | > I wrote [for two classes S with visibility == hidden ] | > > | > | We can have two distinct | > > | > | classes named S, and no one can tell. Each bit of code will see one | > > | > | definition of S. | > | > Jason Merrill <[EMAIL PROTECTED]> writes: | > > | I think that Joe's point is that IF you have two classes named S, then | > > | they're hidden away in separate shared libraries and you can't compare | > > | them, because no piece of code knows about both of them. | > | > Yes. It is sometimes necessary with very large software systems to | > use tricks like this because someone was sloppy about naming (particularly | > in older code that comes from times before namespaces were universally | > available, and many of us do have to deal with 7-10 year old code on | > occasion). | | I don't think you can say 'no piece of code knows about both of them'. | What you can say is that these two classes are both named S but | they're different, just as if they were in different namespaces. That would mirror how C++ handles classes in unnamed namspaces. In other words, the visibility would have to be part of the mangled name. | > On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote: | > > I'm not clear about "you can't compare them". | > > | > > Surely, I can take the address of typeid(S) and pass it around to | > > a function in another translation unit. I can do | > > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes | > > from two such different translation units. | > > | > > How the current visibility framework prevent that from happening? | > | > By a note in the documentation telling the user "don't do that". | | No, there's no such note. The answer is that the two typeids have | different addresses, so one will be before the other, depending on | where the shared libraries got loaded, just as if the classes had | different names. In the case where __GXX_MERGED_TYPEINFO_NAMES is not defined, that would not be true. Because the current definition of type_info::before uses a strcmp() on their mangled name. To make the implementation correct, the mangled name need to incorporate the visibility attribute. And even where __GXX_MERGED_TYPEINFO_NAMES is defined, it appears to me that it is also a Good Thing to incorporate the visibility in the mangled name so that the result of before() becomes deterministic and does not depend on the order of loading of shared libraries. -- Gaby
