Geoffrey Keating <[EMAIL PROTECTED]> writes:
| Jason Merrill <[EMAIL PROTECTED]> writes:
|
| > Gabriel Dos Reis wrote:
| > > Jason Merrill <[EMAIL PROTECTED]> writes:
| > > So, -concretely- what happens to a class S (e.g. associated type
| > > info object
| > > address, address of member functions, etc.) with external linkage,
| > > defined in multiple translation units, with say hidden visibility?
| >
| > If it has hidden visibility then shared objects other than the one
| > with the definition can't do much with it. They can use inline
| > interfaces and interfaces that are explicitly overridden to have
| > default visibility.
| >
| > Anything that relies on weak symbols to unify vague linkage entities
| > across shared objects will break.
|
| I don't think "break" is the right word here. It will behave exactly
| as documented. If you were expecting the two classes to be the same,
| then you'll find won't be, but this is not breakage, it is a fault of
| your expectation---and remember, we have a perfectly good way to make
| sure that the classes *are* the same, which is to give the classes
| default visibility.
I believe I did not communicate correctly the issue. Consider the
(other version of)
current definiton of type_info::before:
#if !__GXX_MERGED_TYPEINFO_NAMES
bool
type_info::before (const type_info &arg) const
{
return __builtin_strcmp (name (), arg.name ()) < 0;
}
#endif
This implementation will make the expression
!typeinfo1.before(typeinfo2) && !typeinfo2.before(typeinfo1)
holds for two such classes that you consider different. That is
inconsistent.
-- Gaby
