This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc visibility used by moz

Daniel Jacobowitz wrote:
On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
If the programmer had intended that the type should appear to not exist. it wouldn't be defined in a header #include-able by client code. The

GCC doesn't know if the header is includable by client code; I assume that's the use Jason intended for marking classes hidden ("it belongs to this shared object and no one else can see it").

No, that's why we need programmer provided attributes. The programmer says:

"the client code needs to know about the existence of this type so it can get pointers and references to instances and pass them back in later and maybe be able to call virtual member functions and access non-static members" by putting it in a header which they document should be included by client code - thus client code includes it and knows about the type. But the programmer says:

"it is documented that the member functions and static members of this type should not need to be accessed outside of the shared object that I will define by use of the linker later on - nor should its constructors/destructors need to be called from outside that shared object, except maybe *this* one and *that* one. Thus the symbols used to lookup those things do not need to be exported from the shared object."

In the examples above, client code that knows (via headers) that the classes exist should be able to get pointers to instances via exported functions, access any visible or virtual members, and pass the pointers back into visible functions of the shared object - or even dereference the pointers to pass by reference.

So... what does it restrict, then? Is it just defaulting methods to hidden, as a strange form of access control?

As above, I thought it wasn't there originally to "restrict" anything, but to remove stuff from symbol tables that the programmer knows don't need to be there, but the compiler has no way of working out - the purpose for which most annotations in C++ are there.

If all code that refers to a type's name (and possibly one or more members) and that will be compiled to a different shared object file (or executable) does not need the symbols for some parts of that class's definition to be exported, then the symbols do not need to be exported from the shared object in which their instances appear. This provides a large space saving, and startup time improvement. That does not require that all symbols whose C++ prototypes say they return a pointer or reference to a "hidden" type are also hidden.

Tristan Wibberley

These opinions are my own, and do not reflect those of my employer.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]