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

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

[Vivenzio Pagliari]

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.

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

[John Carter]

On Wed, 2 Oct 2002, Vivenzio Pagliari wrote:

> 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??

I suspect nobody does and nobody should, but to change the compiler so 
that it didn't would make it non-standard. (I can imagine one place where 
I would use that feature, suppose some of the class implementation is 
crafted by hand, some of it generated.)

Conversely it shouldn't ever be a problem to you unless you are getting 
name space conflicts. At which point you should start using the namespace 
feature of the standard anyway.

-- 


John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Good Ideas:
Ruby                 - http://www.ruby-lang-org - The best of perl,python,scheme without the pain.
Valgrind             - http://developer.kde.org/~sewardj/ - memory debugger for x86-GNU/Linux
Free your books      - http://www.bookcrossing.com