Re: gcc visibility used by moz

[Tristan Wibberley <maihem at maihem dot org>]

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.