From -9018215008697879561 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,fe953dde0d9fda91 X-Google-Attributes: gidf78e5,public Path: controlnews3.google.com!news1.google.com!newshub.sdsu.edu!newshosting.com!nx02.iad01.newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: s_googlegroups@nedprod.com (Niall Douglas) Newsgroups: comp.std.c++ Subject: Re: n1496 Date: Fri, 28 May 2004 02:02:03 +0000 (UTC) Organization: Esat Net Customer Lines: 59 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <86vfiuq081.fsf@Zorthluthik.local.bar> <60c4o1-1e2.ln1@interbusiness.it> <1cmco1-u72.ln1@interbusiness.it> <86hdu14y8d.fsf@Zorthluthik.local.bar> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1085709723 14446 10.0.0.1 (28 May 2004 02:02:03 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 28 May 2004 02:02:03 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 1BTWh8-0003kr-00 for mail2news@news.news.demon.net; Fri, 28 May 2004 02:02:02 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i4S220L0013243; Fri, 28 May 2004 12:02:00 +1000 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i4S220EY013234; Fri, 28 May 2004 12:02:00 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: Thu, 27 May 2004 22:51:03 +0000 (UTC) X-User-Agent: Opera7.21/Win32 M2 build 3218 X-Spam-Checker-Version: SpamAssassin 2.60-mulga_r1 (1.212-2003-09-23-exp) on mulga.cs.mu.OZ.AU X-Spam-Status: No, hits=-4.9 required=5.2 tests=AWL,BAYES_00 autolearn=ham version=2.60-mulga_r1 Xref: controlnews3.google.com comp.std.c++:537 On Thu, 27 May 2004 17:17:54 +0000 (UTC), llewelly wrote: > s_googlegroups@nedprod.com (Niall Douglas) writes: > [snip] >> Note that for every symbol which is available outside its DSO, a >> particularly expensive form of relocation must also be performed at >> load time which on all implementations I know of is quadratic to >> symbol number. See Ulrich Drepper's "How to write shared libraries". > [snip] > > This is actually an argument for having symbols not visible by > default. An *implementational* argument for having symbols not visible by default. With a C++ hat on, one would say that it's the compiler & linker's problem to most efficiently turn my C++ into the best binary possible. However with an implementational hat on, one quickly realises that's far from trivial without additional annotation in the source. The original poster felt that the compiler & linker could do just fine with symbols default public. I was illustrating that default public comes with unacceptable costs and even with improved compiler technology it's not going to change any time soon. >> No you're wrong here. A static symbol is indeed hidden in that it >> cannot be directly referenced outside its compiland. This is not true >> for the contents of unnamed namespaces - they merely add extra >> mangling to the symbol which actually makes the problem worse (longer >> load & linking times and more code bloat). > > This is true for current implementations, but does it *need* to be > true? > > Why might an implementation need to make a symbol inside a unnamed > namespace visible at dynamic link-time? Off the top of my head, if a type with a vtable were defined within the unnamed namespace and then a pointer to it typeid()'d in some other compiland the compiler would need the typeinfo to be available. Therefore it probably needs to be true - it's certainly /easier/ if it's true. Certainly it's true everywhere I've seen so far. If a linker were more clever, it could speculatively hide symbols which weren't used but that breaks if you use shared libraries where it must export everything just in case. Again, an argument for extra annotation of the source. Only the programmer can really say if a symbol will be used externally or not. Cheers, Niall --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]