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). 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". I think it's safest just to say that if people want to use hidden visibility to violate the ODR, and they succeed in getting a pointer to class S from libfoo.so, and a pointer to the distinct class S from libbar.so, into the same hunk of code and then try to compare the typeinfo objects, that we simply don't define what happens. I think it would be a mistake to try to define the semantics in this case.
