public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Vivenzio Pagliari <vivenzio@web.de>
To: GCC Help <gcc-help@gcc.gnu.org>
Subject: Visibility of C++ class private symbols (as compared to static)
Date: Wed, 02 Oct 2002 03:16:00 -0000	[thread overview]
Message-ID: <3D9AC923.8060207@web.de> (raw)

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.

             reply	other threads:[~2002-10-02 10:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-02  3:16 Vivenzio Pagliari [this message]
2002-10-03 15:35 ` John Carter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D9AC923.8060207@web.de \
    --to=vivenzio@web.de \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).