RFC: C++: __attribute__((visibility)) for classes

[Matt Austern <austern at apple dot com>]

When you define a C++ class, you get tons of symbols related to the 
class itself.  Consider, for example:
  struct abcd { virtual ~abcd(); };
  abcd::~abcd() { }
Compiling this shows that abcd's class definition gives us the 
following symbols symbols:
  _ZN4abcdD0Ev
  _ZN4abcdD1Ev
  _ZN4abcdD2Ev
  _ZTI4abcd
  _ZTS4abcd
  _ZTV4abcd
OK, maybe listing the three symbols for the destructor is cheating, 
since they directly correspond to a function the user wrote, but 
_ZTI4abcd, _ZTS4abcd, and _ZTV4abcd are another matter.  These symbols 
correspond to class metadata.  They're things the compiler generates to 
support the object model, and they don't directly correspond to 
anything in the user's source.

As far as I can tell, we don't provide any way to control the 
visibility of those symbols.
If you try writing
  struct  __attribute__((visibility("hidden"))) abcd { virtual ~abcd(); 
};
then the compiler informs you that visibility only applies to function 
and variable declarations, not type declarations.  Or if you write
  __attribute__((visibility("hidden"))) abcd::~abcd() { }
then you get something useless: a class whose vtable (and RTTI symbols, 
etc) have normal visibility, but whose destructor is hidden.

I believe that any sensible solution has to be in the compiler.  Asking 
users to explicitly list the symbols they want to hind is unreasonable: 
ordinary users shouldn't have to know which classes will need VTTs, 
construction vtables, and the like, and certainly shouldn't have to 
know the mangled names for those ghastly things.  Even your average 
guru would probably get it wrong most of the time.  I'm sure I would.

My suggestion: allow visibility attributes on class definitions.  
Giving a class nondefault visibility means giving that visibility to 
all of its member functions, static member variables, and metadata.

This doesn't do everything that everyone might need, and I'm sure we 
could add extra features later.  But it strikes me as a pretty obvious 
and low-impact extension of what the visibility attribute already does, 
and it should meet the needs of most users who want to combine 
nondefault visibility with C++.

If people think something like this might be a good idea, I'll submit a 
patch.

			--Matt