From -6669940779891434099 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!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: 6805b3x001@sneakemail.com (Davide Bolcioni) Newsgroups: comp.std.c++ Subject: Re: n1496 Date: Sun, 23 May 2004 00:18:04 +0000 (UTC) Organization: TIN Lines: 86 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <60c4o1-1e2.ln1@interbusiness.it> References: <86vfiuq081.fsf@Zorthluthik.local.bar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: mail2news.demon.co.uk 1085271484 2656 10.0.0.1 (23 May 2004 00:18:04 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sun, 23 May 2004 00:18:04 +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 1BRggl-0000gh-00 for mail2news@news.news.demon.net; Sun, 23 May 2004 00:18:04 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i4N0I1PT028637; Sun, 23 May 2004 10:18:01 +1000 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i4N0I1ET028628; Sun, 23 May 2004 10:18:01 +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-User-Agent: Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.4.1) Gecko/20031114 X-Accept-Language: it, en X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: Sat, 22 May 2004 18:35:11 MET DST X-Spamscanner: mailbox3.ucsd.edu (v1.4 May 20 2004 13:55:33, 1.4/5.0 2.63) X-MailScanner: PASSED (v1.2.8 2026 i4MGZDFj014147 mailbox3.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=-4.1 required=5.2 tests=BAYES_00,FROM_ENDS_IN_NUMS, FROM_HAS_MIXED_NUMS autolearn=no version=2.60-mulga_r1 Xref: controlnews3.google.com comp.std.c++:425 Niall Douglas wrote: >> 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. From the point of view of a programmer doing mostly maintenance work of existing code bases, I would say that Unix had it right from the beginning and Windows requires the programmer to pepper the code with too much detail for his own good: the notion that shared libraries are not something which should concern the language, only the linker, made my job exceedingly easier. If you want metaphors, think relational versus handcrafted database, with the linker doing the joins. > BTW in N1496 appendix item 4 I can confirm that the Unix mechanism > cannot be implemented on Windows. Given the time scale expected of C++0x, maybe the right question is whether it is implementable for .NET ? > 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). This should be of interest only to people implementing a linker, in my opinion. >> 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. From the point of view of maintenance ... I would personally dislike that intensely :-). > 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. Which is an implementation detail which I expect the linker to handle, although the PE linker doesn't. > 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. Unix shared libraries implement visibility as defined in the C or C++ language, without introducing another layer of detail for the programmer to handle (and possibly get wrong). Programmers wishing for the additional complexity might have the option to specify it, but the default should be implementation-defined (in the makefile) linking. In other words: we don't tell the programmer how the program will be cobbled together, he had better make sure it works anyway. Guidelines as to which tricks not to pull in order to not have things break unexpectedly would be really welcome and in my humble opinion belong in a language standard: FORTRAN got much mileage from its rules for common variable access, for example. > 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. On the contrary, I suggest leaving the language as it stands; just acknowledge that shared libraries are a reality of current implementations and might impose a series of restrictions which should be observed by the programmer. Best Regards, Davide Bolcioni --- [ 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 ]