gcc visibility used by moz

[Tristan Wibberley]

Daniel Jacobowitz wrote:
> On Wed, Jul 12, 2006 at 07:49:21PM +0100, Tristan Wibberley wrote:
>> 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."
> 
> I just don't get it.  Why should it matter whether a member function is
> virtual or not in order to be able to call it from outside this shared
> object?  Either you can access the public members of the class, or you
> can't.  Being able to access some of them and get link errors on others
> is a very strange default interpretation.

Because virtual functions don't require anything to be exported from a 
shared object other than a function to get a pointer to an instance.

 From C++'s point of view, the hidden attributes should have no effect. 
 From the linker's point of view, they document what the code that links 
to a shared object will not be using, and so what symbols do not need to 
be exported.

-- 
Tristan Wibberley

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