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