Gabriel Dos Reis wrote:
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
| > 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?
|
| Well, there are the C++ rules, and then there are the ELF rules. At the
| object code level we have only symbol definitions (corresponding to
| the addresses of member functions, virtual tables, and typeinfo). If
| the relevant symbols are hidden, then it's as if they aren't there, so
| we can violate the one-definition rule.
Thanks. So both notions are not as orthogonal as they may appear.
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.
But I think it is important that there are three places where visibility
is a factor (as a concept of "being able to see things" rather than the
attribute).
1) If a class definition is not present in a given translation unit, but
a class declaration is, then the translation unit may normally pass
around a pointer to an instance of that class and also a reference to an
instance of that class, but may not do anything else with it.
2) Until now, the visibility attribute was used for optimising symbols
exported from a .so for when things will only be used within that .so
(but used across its constituent .o files). Saving unnecessary runtime
costs and non-volatile storage costs. This is really valuable and I'd
like to see it remain available.
The last is the interesting case, which it seems 2) has broken while
this was being worked on.
3) For file scope functions and file scope variables, the static keyword
is overloaded to indicate that their definition should be created for
this translation unit such that it is a unique function or variable even
if other functions or variables use the same name in both translation
units. I can see that something could be desirable to define classes
just for the internal behaviour of a translation unit without having to
consider name conflict, but the unnamed namespace should do that
shouldn't it? Which also satisfies the ODR since each unnamed namespace
in separate translation units is a different one.
It kind of makes sense to hide functions that take arguments or return
pointers to types in the translation unit unnamed namespace (but that is
so easy for the programmer to cause just by putting the prototype into
the unnamed namespace that its not worth doing anything fancy other than
warning since they may be trying to do some clever multi-language
interoperability thing.
--
Tristan Wibberley
These opinions are my own, and do not reflect those of my employer.
