Gabriel Dos Reis wrote:
Tristan Wibberley <[EMAIL PROTECTED]> 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.
