r175587 - Add a new 'type_visibility' attribute to allow users to

John McCall rjmccall at apple.com
Wed Feb 20 12:19:28 PST 2013


On Feb 20, 2013, at 8:49 AM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:
>> Add a new 'type_visibility' attribute to allow users to
>> control the visibility of a type for the purposes of RTTI
>> and template argument restrictions independently of how
>> visibility propagates to its non-type member declarations.
> 
> Could you pleas add a bit of user documentation on to how this should
> be used? What is the intended use case? Exporting a class with only
> virtual methods? If so, shouldn't the constructors also get the type
> visibility?

Users who want to minimize the set of symbols they export from their
dynamic libraries usually compile with -fvisibility=hidden.  They then
find themselves going back and marking certain classes with default
visibility.  They then find themselves with extra symbols again because
the inline functions from those class are now default visibility.
It's all really a huge pain.

The point of type_visibility is that you can give your RTTI symbols
default visibility, and therefore make dynamic_cast and exceptions
work across dynamic library boundaries, without affecting any other
visibility calculations.

libc++ in particular can actually go and mark all of its exported classes
with type_visibility("default") and visibility("hidden"), and suddenly,
regardless of compilation mode, RTTI symbols will be properly
exported and nothing else will.

The only way of achieving that right now is to put DEFAULT on the
class and then individually mark every single method declaration
with HIDDEN.

You're right that I should make user docs, though.

John.



More information about the cfe-commits mailing list