From 5717161457319845286 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,fe953dde0d9fda91 X-Google-Attributes: gidf78e5,public Path: controlnews3.google.com!news1.google.com!news.glorb.com!newsrout1.ntli.net!news-in.ntli.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: Sat, 29 May 2004 15:49:01 +0000 (UTC) Organization: Esat Net Customer Lines: 92 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> <959io1-hm3.ln1@interbusiness.it> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1085845741 6079 10.0.0.1 (29 May 2004 15:49:01 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 29 May 2004 15:49:01 +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 1BU64y-0001Zt-00 for mail2news@news.news.demon.net; Sat, 29 May 2004 15:49:00 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i4TFmvL0011773; Sun, 30 May 2004 01:48:57 +1000 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i4TFmv6b011764; Sun, 30 May 2004 01:48:57 +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: Fri, 28 May 2004 18:30:47 +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=BAYES_00 autolearn=ham version=2.60-mulga_r1 Xref: controlnews3.google.com comp.std.c++:552 On Fri, 28 May 2004 02:05:20 +0000 (UTC), Davide Bolcioni wrote: > Supporting (c) indeed seems to require double indirection; however, I > recollect investigations from KDE people about C++ dynamic linking in > Linux showing that relocations, not indirection, were the main source > of overhead and suggesting prelinking as a solution. Absolutely. If however every symbol access requires an address fetch in order to determine where to fetch the data, you create very nasty pipeline stalls on modern processors as that singularly defeats any prediction unit in the CPU. > If I write that a member function is private, I mean exactly that; it > cannot be called from outside the class. The mangled symbol for its > implementation should not require double indirection to reach, once > WPO coalesces invocations from separate .o files; if the programmer > puts some implementations in a .so and some in another, double > indirection would be required and a comment in the standard should > warn of the associated performance cost. Most programmers would > not do that. Thing is, it must remain publicly visible in case a friend class wants it. And bear in mind that the linker rarely knows anything about C++ at all, it just blindly assembles object files. > The above, however, still allows the programmer to overwrite symbols > through linker directives, or even by making the "mistake" of putting > the implementations he wants to override in a separate .so, causing > the compiler to use double indirection and all that. Y'see, I would argue that the costs of being able to override symbols like this aren't worth it given the amount of code that will ever use such a feature. Far better such code does it explicitly so everyone else can run much faster. > If I write public I mean public - anybody can call a public function > from anywhere, which is essentially analogous to the protected case > from the point of view of linking. What if it's public to classes within your DSO but not to anything outside? >>> a syntactic construct to address it on a symbol by symbol >>> basis is inappropriate. > > My key objection is to "on a symbol by symbol basis", which is a critique > of n1496; the choice of "default hidden" would exacerbate the problem. My concern is that what you seem to want would need a much more intelligent linker. Linkers work in terms of symbols and thus why one specifies visibility on a per-symbol basis. I'm not sure moving that way is the right one. >> Also I like how right now things can be subdivided one way at the >> source level (via namespaces) but a totally different way at binary >> level - to me, this ADDS value through intuitiveness. > > I both agree and disagree; I agree that some latitude in the organization > of code at binary level is highly desiderable, but only as long as this > does not break the contract established by the C++ language. Bear in mind that C++ isn't the only linkable language - many languages output ELF object formats some of which can even be directly linked with C++ (though mostly it's just C). What you propose would suggest breaking with such a capacity. > Allowing multiple definitions of the same symbol in separate packages > would cause a violation of the ODR rule, but only if said packages > are ever collected together as a C++ program. How do you handle a program loading an unknown library (package) at run time? > All things considered, the above seems a little too much for saving one > indirection from nonvirtual functions; maybe the module/package concept > can bring other benefits from C++, however. Of course, one could simply mandate the Win32 method of doing shared libraries and all these problems on ELF go away. ELF itself as a format can handle it easily - it's just the semantics of working with shared libraries need to change (in a non-breaking fashion with how it's currently done). 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 ]