From -2861684774681652869 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!peer1.news.newnet.co.uk!peer1.news.newnet.co.uk!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: Thu, 20 May 2004 02:52:54 +0000 (UTC) Organization: Esat Net Customer Lines: 72 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <86vfiuq081.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 1085021574 21792 10.0.0.1 (20 May 2004 02:52:54 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 20 May 2004 02:52: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 1BQdfx-0005fL-00 for mail2news@news.news.demon.net; Thu, 20 May 2004 02:52:53 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i4K2qoPT019561; Thu, 20 May 2004 12:52:50 +1000 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i4K2qosg019551; Thu, 20 May 2004 12:52:50 +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, 20 May 2004 00:52:45 +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-Level: 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++:378 On Mon, 17 May 2004 21:09:47 +0000 (UTC), llewelly wrote: > # There are three possible approaches to specifying which names in > # a translation unit refer to entities with shared linkage. First, > # names with external linkage can be non-shared by default, and the > # programmer would have to explicitly identify names that are to > # have shared linkage. This is the model that Windows programmers > # are familiar with. Second, names with external linkage can be > # shared by default, and the programmer would have to explicitly > # identify names that are not to have shared linkage. This is > # similar to the model that UNIX programmers are familiar > # with. Third, it can be implementation-defined which of the two > # preceeding models applies. This minimizes the required changes to > # existing code. > > I'm unhappy with the first model because it seems to break all > existing unix code that makes use of shared libraries. One could take the view that Unix has it wrong and it needs to change for its own good. Irrespective of what the standard says, the implementors on Unix will devise some transitory/interoperability strategy. It would also hardly be the first time that existing implementations did something which was later ruled out by the standard (I'm thinking unqualified name lookups within templates particularly). BTW in N1496 appendix item 4 I can confirm that the Unix mechanism cannot be implemented on Windows. The PE binary hardcodes what symbols it looks for from each library by name as of course under PE you can use ordinal rather than mangled symbol resolution. The advantage of the PE system is a substantially reduced search tree and thus improved load & link times but it does mean you can't arbitrarily muck around with DLL contents without a relink (not hard as ELF dynamic loaders ARE the full-strength standard linker). > I'm unhappy with the second model becuase it changes the default on > windows; it seems to cause every declaration to undergo a silent > change in meaning. N1496 also doesn't cover the need to use dllimport with PE for variables. You can get away with not specifying dllimport for functions on Win32 but you *must* specify it for variables. > I don't think either of the first two models should be accepted. I think the first model should be mandated. Unix shared libraries emulate static linking except that the linking is continuous in that it can be more-done or be undone according to manual loading and unloading of libraries. Certainly from a programmer's point of view, you are supposed to do nothing special to use shared libraries - just tweak your build system slightly with no source changes. However the reality is more complex than that. Because Unix shared libraries seek to provide this legacy appearance, they diverge much less from not only the standard but also the spirit of static linking. Therefore one could view that system as "enhanced static linking" and therefore not something which needs to be borne in mind when updating the ISO C++ standard. In other words, what I'm saying is that a MSVC style shared library system can coexist with the Unix shared library system whereas the opposite is most certainly not true. Therefore be brave and go with system number 1. 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 ]