------- Comment #2 from ak dot miller at auckland dot ac dot nz 2006-08-21 01:48 ------- (In reply to comment #1) > I don't see why this is a problem?
One of the main uses for visibility is to hide symbols to reduce the size of shared objects, and to ensure that people don't use libraries in ways which are inappropriate. In this case, if I know that no external code is going to extend from Foo, but will perform dynamic_cast<Foo*>(ptr), I have to ensure that _ZTI3Foo is not hidden. However, since there is no way to do this: 1) I have no choice but to also export _ZTV3Foo, _ZTT3Foo, and possibly a number of construction vtables. This means that I have a larger than necessary set of visible symbols, which increases the size of the binary, as well as link times. 2) External code can link against the library, and extend from Foo. However, in a subsequent version of the library (which is supposed to be binary compatible) the meaning of protected members might change, causing unexpected problems. 3) This could allow for the compiler to perform space optimisations in the future (for example, dropping construction vtables which are never needed, and are also hidden). > In fact I think you can get into a problem > with the C++ One definition rules. I'm not saying that this should be supported in order to allow for the same name to be used in another compilation unit, and in fact, if you wanted to do this you would hide everything, or the typeinfo would conflict. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28786
