Geoffrey Keating <[EMAIL PROTECTED]> writes:
| 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.
If we don't have visibility attribute comes into the picture, then I
think we don't have the problem in the first place precisely because
of the One Definition Rule. My example of inconsistency was this:
typeinfo1 != typeinfo2
and yet
!typeinfo1.before(typeinfo2) && !typeinfo2.before(typeinfo1)
The last conjuction should be false if we had the visibility stuff
correct. I.e. one of typeinfo1 and typeinfo2 must be before the other,
but we can't say exactly which one. The predictability is a QoI, and
holds only for platforms whether __GXX_MERGED_TYPEINFO_NAMES is not
defined. Thats aspect is indeed independent of visibility. However the
logical expression above becomes an issue when we have the visibility
attribute.
-- Gaby
