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]

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

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:
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.


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