Jason Merrill <[EMAIL PROTECTED]> writes:

| Gabriel Dos Reis wrote:
|  >> Joe Buck wrote:
| > Now, this being a conscious decision for ODR violation, it would
| > probably need to be documented because then we may have
| >    typeinfo1 != typeinfo2
| > and yet
| >     !typeinfo1.before(typeinfo2) && !typeinfo2.before(typeinfo1)
| > There are probably other inconsistencies to audit.
| > | We can have two distinct
| > | classes named S, and no one can tell.  Each bit of code will see one
| > | definition of S.
| 
| 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.

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?

[storing the address of typeid(S) is usually found on variations on
the Factory design pattern.]


|  Any class
| that is part of the public interface of a shared library is part of
| the public interface, and therefore must be unique through the program.

Yes.  One of the interesting parts is what happens when those classes have
external linkage but hidden visibility.

| In any case, this ODR business seems rather tangential to the
| discussion of visibility semantics.  The primary purpose of the
| visibility work is limiting the number of symbols exported from a
| particular shared library in order to cut down on load time.  Can we
| please focus on the semantics we want for that instead of trying to
| solve a theoretical problem that has been around as long as people
| have tried to use shared libraries with C++?

I think we can assume that people are focusing on the semantics.
However, we should not handwave serious ODR issues.  We have gotten
lots of PRS from real codes against the visibility stuff due to
reasons I would trace to "oh, that issue should not matter in
practice".  The complexity of the issue should push us to hide under
the cover of theoretical problem :-) 

Because of the semantics of type_info objects, it is not clear to me
yet how the ODR issue is orthogonal to the visibility semantics.

An easy way out may to be to declare the combination 

   external linkage + hidden visibility

for the "same" class in differrent translation units as an ODR
violation, i.e. the program has an undefined behaviour.  That puts a
restriction, that might be considered "severe" or not.

-- Gaby

Reply via email to