From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21086 invoked by alias); 2 Oct 2002 10:16:14 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 21039 invoked from network); 2 Oct 2002 10:16:12 -0000 Received: from unknown (HELO smtp.web.de) (194.45.170.210) by sources.redhat.com with SMTP; 2 Oct 2002 10:16:12 -0000 Received: from b-180-177-215.s.dial.de.ignite.net ([62.180.177.215] helo=web.de) by smtp.web.de with asmtp (WEB.DE(Exim) 4.75 #2) id 17wgY7-0001ot-00 for gcc-help@gcc.gnu.org; Wed, 02 Oct 2002 12:16:11 +0200 Message-ID: <3D9AC923.8060207@web.de> Date: Wed, 02 Oct 2002 03:16:00 -0000 From: Vivenzio Pagliari User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: GCC Help Subject: Visibility of C++ class private symbols (as compared to static) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00015.txt.bz2 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.