gcc visibility used by moz

[Tristan Wibberley]

Gabriel Dos Reis wrote:
> Tristan Wibberley <maihem@maihem.org> writes:

> | 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 strikes as you are assuming C and C++ have a notion of module.
> They don't.  They have the notion of "translation unit."  C++ adds the
> notion of "One Definition Rule" to make sure Bad Things don't happen.
> You have to operate within that framework if you're going to touch the
> C++ type system in any way.

No but the linker does, and that's the program for which the attributes 
are intended. C++ doesn't even have a concept of "visibility", so C++ 
isn't really the matter here. The visibility attributes should simply 
map to the symbols used to export the thing that the visiblity attribute 
is applied to so the linker can pick them up as the programmer expects.

I am suggesting that visibility attributes should *not* touch the C++ 
type system in any way. Since C++ doesn't have a notion of module a 
class that the C++ type system regards as hidden must be hidden from 
everything (in which case, you could just comment out the class 
definition instead) or nothing. I suggest that should be nothing, and 
that the linker should apply the visibility attributes to *its* notion 
of module.

-- 
Tristan Wibberley

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