Joe Buck <[EMAIL PROTECTED]> writes: > 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? > > Joe Buck <[EMAIL PROTECTED]> writes: > > > By a note in the documentation telling the user "don't do that". > > On Fri, Jul 14, 2006 at 11:34:18AM -0700, Geoffrey Keating wrote: > > 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. > > We're in complete agreement. What I meant was to say that if Gaby is > worried over user confusion on this point, we'd add a warning that > the result isn't defined, but I expressed it in a sloppy way. I know > that the documentation currently says nothing on the matter.
Oh, I see. The definition for 'before' in the standard says > true if *this precedes rhs in the implementation's collation order. and 'collation order' is not-specified as: > The names, encoding rule, and collating sequence for types are all > unspecified and may differ between programs. I guess we could say that even for the same binary, the collating sequence still might differ between runs of the binary (on systems like Linux where the library load addresses vary randomly); or you could just try to fit that under the definition of a 'program'. However, this is not a visibility-related issue, since the exact same thing happens even if you don't use any visibility control at all, and just have two differently-named classes in different shared objects.
