Jason Merrill wrote:
It seems that you have a different mental model of type visibility. The way I was thinking about it, if a type has hidden visibility, we can't refer to it from outside its object. Thus, it doesn't make sense for members or objects with that type to have greater visibility because even if people can call the accessor they can't do anything with the return value.
>
However, I'm not attached to this in defiance of practical concerns. What is your model of type visibility?
This isn't "type" visibility. Shared objects don't export "types" they export "symbols". The types are defined in headers and are thus known to exist - no visibility attributes will or should change that.
If the programmer had intended that the type should appear to not exist. it wouldn't be defined in a header #include-able by client code. The compiler should assume that the type exists and can be used if it is defined and shouldn't change attributes on other parts of the program.
In the examples above, client code that knows (via headers) that the classes exist should be able to get pointers to instances via exported functions, access any visible or virtual members, and pass the pointers back into visible functions of the shared object - or even dereference the pointers to pass by reference.
-- Tristan Wibberley These opinions are my own, and do not reflect those of my employer.
