Visibility of C++ class private symbols (as compared to static)

Vivenzio Pagliari vivenzio@web.de
Wed Oct 2 03:16:00 GMT 2002


Hello,

I'm trying to understand the issue of symbol visibility
and external/internal linkage (in particular for shared
libraries and using C++),

Just for easier explanation, here an example:

A typical header file might look like:

---> Foo.h <---
class Foo
{
public:
     int foo(int i);

private:
     int bar(int i);

     int i_;
     static char const* s_;
};
---> end of Foo.h <---

Usually, the implementation is in one compilation unit -- Foo.cc.
Talking about this usual case, it would be sufficient for the
symbols Foo::bar(int) and Foo::s_ to be local (internal linkage).

Instead, they have external linkage and could be used from outside.
(I've seen such a hack in mico, using a "#define private protected"
to override compile-time access control.)
Additionally, if Foo.o will be part of a shared library, these
symbols will increase (unnecessarily) the dynamic symbol table.

My question now is: How can I give private class
symbols internal linkage by default (since this is enough in
the most common cases)? Or is it necessary for some other reasons
to have external linkage for these symbols?

In theory, class Foo could be implemented in different compilation
units and thus require external linkage of the symbols. Even more,
the resulting object code could be split up in different libraries
(eg. Foo::bar(int) in libfoo1.so and Foo::s_ in libfoo2.so),
requiring eg. the entries in the dynamic symbol table.
But who does this or who needs this??

Thanks,
Vivenzio

-- 
Do not believe in miracles -- rely on them.



More information about the Gcc-help mailing list