* Visibility of C++ class private symbols (as compared to static)
@ 2002-10-02 3:16 Vivenzio Pagliari
2002-10-03 15:35 ` John Carter
0 siblings, 1 reply; 2+ messages in thread
From: Vivenzio Pagliari @ 2002-10-02 3:16 UTC (permalink / raw)
To: GCC Help
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Visibility of C++ class private symbols (as compared to static)
2002-10-02 3:16 Visibility of C++ class private symbols (as compared to static) Vivenzio Pagliari
@ 2002-10-03 15:35 ` John Carter
0 siblings, 0 replies; 2+ messages in thread
From: John Carter @ 2002-10-03 15:35 UTC (permalink / raw)
To: Vivenzio Pagliari; +Cc: GCC Help
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-10-03 22:35 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-02 3:16 Visibility of C++ class private symbols (as compared to static) Vivenzio Pagliari
2002-10-03 15:35 ` John Carter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).