From -4928615042402485641 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,fe953dde0d9fda91 X-Google-Attributes: gidf78e5,public Path: controlnews3.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed.mathworks.com!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: llewelly.at@xmission.dot.com (llewelly) Newsgroups: comp.std.c++ Subject: Re: n1496 Date: Thu, 27 May 2004 17:17:54 +0000 (UTC) Organization: The Illusory Sorting Algorithm Lines: 62 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <86hdu14y8d.fsf@Zorthluthik.local.bar> References: <86vfiuq081.fsf@Zorthluthik.local.bar> <60c4o1-1e2.ln1@interbusiness.it> <1cmco1-u72.ln1@interbusiness.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: mail2news.demon.co.uk 1085678274 8728 10.0.0.1 (27 May 2004 17:17:54 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 27 May 2004 17:17:54 +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 1BTOVt-0002Gd-00 for mail2news@news.news.demon.net; Thu, 27 May 2004 17:17:53 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i4RHHplp010016; Fri, 28 May 2004 03:17:51 +1000 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i4RHHpbf010007; Fri, 28 May 2004 03:17:51 +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 16:44:13 +0000 (UTC) X-User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (berkeley-unix) X-Cancel-Lock: sha1:svUbnzRMXsi6jDwf5ARQUitkBAw= X-SA-Exim-Mail-From: news@xmission.com X-SA-Exim-Version: 3.1 (built Wed Aug 20 09:38:54 PDT 2003) X-SA-Exim-Scanned: Yes X-Spamscanner: mailbox4.ucsd.edu (v1.4 May 20 2004 13:55:33, 1.1/5.0 2.63) X-MailScanner: PASSED (v1.2.8 24473 i4RGiFq8044259 mailbox4.ucsd.edu) 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=-3.6 required=5.2 tests=AWL,BAYES_00 autolearn=ham version=2.60-mulga_r1 Xref: controlnews3.google.com comp.std.c++:524 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. > >>> This is partially where the speed & size differential between MSVC >>> & GCC compiled binaries comes from. The trouble with "default >>> shared" is that it encourages laziness - most programmers will do >>> the minimum to get a working application and then stop. If it's >>> "default private" then programmers must add the extra annotation to >>> even reach a working binary - which is good, because code quality >>> improves substantially. >> >> In C, to hide a symbol you make it static. In C++ we have the unnamed >> namespace and access specifiers for classes; this might or might not >> be enough to provide the information you need for faster binaries, so >> it might prove helpful to address this in the standard along the lines >> of "if you do such and such, the translator might be forced to assume >> that and produce underperforming code". >> >> In other words, C/C++ programmers already take a visibility decision in >> the code, using the language-provided means which the underlying >> implementation is required to support. > > 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? > Why don't unnamed > namespaces hide their contents? Because "export" causes searching of > unnamed namespaces outside its compiland! [snip] A typical unix runtime linker has niether the smarts nor the information availible to do the name lookup needed by exported templates. Further, some experts have claimed it will probably never be beneficial to instantiate exported templates at program load time anyway. So I think this is a bogus argument. --- [ 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 ]