From 2333999473827004201 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,7b8ff869fe5b7ef5 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-11-24 09:22:16 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!fr.ip.ndsoftware.net!212.27.32.7.MISMATCH!proxad.net!proxad.net!194.159.246.34.MISMATCH!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: kanze@alex.gabi-soft.fr (James Kanze) Newsgroups: comp.std.c++ Subject: Re: compilers that implement the keyword 'export' Date: Mon, 24 Nov 2003 17:22:14 +0000 (UTC) Organization: James Kanze Lines: 101 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <86brr2zvsm.fsf@alex.gabi-soft.fr> References: <3cad08b8.0311171811.2760c086@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: mail2news.demon.co.uk 1069694534 23225 10.0.0.1 (24 Nov 2003 17:22:14 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 24 Nov 2003 17:22:14 +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 1AOKPc-00062S-00 for mail2news@news.news.demon.net; Mon, 24 Nov 2003 17:22:13 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id EAA27920; Tue, 25 Nov 2003 04:22:07 +1100 (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-User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.93 X-Spamscanner: mailbox2.ucsd.edu (v1.4 Oct 30 2003 22:20:52, 0.0/5.0 2.60) X-MailScanner: PASSED (v1.2.8 39842 hANKEU36039801 mailbox2.ucsd.edu) X-Spam-Status: No, hits=-6.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_GNUS_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id EAA27920 Xref: archiver1.google.com comp.std.c++:503 stephen.clamage@sun.com (Steve Clamage) writes: [...] |> These template compilation models do not have semantics identical to |> the export model, but I think the semantic model is easier to |> understand than the export model. Does the non-exported template model have the semantics required by the standard? Is the difference due to the different implementation of "separate compilation", or simply that Sun (like many others) hasn't fully implemented the subtilities of the standard model en general. |> The export model requires synthesis of a compilation environment |> that combines the environment of the template definition and the |> point of template instantiation. The Cfront model in effect inserts |> the template definition in the module where it is referenced. Exported or not, the standard has a complicated set of name lookup rules which means that the compiler must consider two distinct "environments" when it instantiates a template. The two environments aren't quite the same when export is involved, but other than that, the problem is in fact the same. Of course, the intent of export was, I think, to allow compiling template code without the implementation sources. Something that CFront allowed, for example (but with radically different lookup rules, and a somewhat different definition of the instantiation context, too, I think). That means somehow saving, or recreating, the instantiation context outside of the compilation. |> Some people have the mistaken idea that exported templates allow you |> to distribute a library of templates without providing source code |> for the templates. Implementers keeps saying that people are saying this, but I've never actually heard anyone say it, or even wish it. It's not a real problem, and if it were, it is easily solvable, even without export. (Sun has delivered template libraries without human readable sources in the past.) What is important, of course, is that if I have 100 or more modules using one particular template instantiation, and I modify the implementation of that template, I don't have to recompile all of the client code. This IS true for the Comeau implementation, for example. Note that the real problem here IS source code organization, and the way makefiles work. With the Sun implementation, there is no real reason to compile more than what Comeau will recompile, export or not. But the "standard" source code organization without export means that this is not what the makefiles will think, and that in practice, I will recompile all of the client code. |> Unfortunately that isn't the case. If a template instance needs to |> be created, the source code for the template must be available. Something must be available. Currently, in all implementations I know, that something is the source code, albeit not necessarily in human readable form. (In some cases, at least with Sun CC 4.2, it was encrypted.) There is, however, certainly nothing to prevent using a pre-tokenized binary format; I've not really studied the issue, but I imagine that one could also develope some sort of byte code which would contain enough information. And let's face it, this sort of byte code is the way compilers are going anyway. To be really efficient, final optimization must be deferred to the link phase, when all of the code is visible, and the output from the compilation of a single translation unit will be some sort of byte code with considerably more semantic information than most current object file formats. But of course, not many compilers are there yet. |> The export model provides makes it easier to tell the compiler that |> a referenced template instance is provided elsewhere. It also changes the semantics. I'm not sure that this is a good thing, although if anything, all templates should have the semantics of export. =20 But the problem goes beyond templates, and affects anything that must be seen by more than one compilation unit. What about the recent complaint that including (or was it ) in g++ defined a macro named minor? There is a fundamental problem in C++ here, and if we are going to solve it (supposing it is solvable without completely breaking everything), I would prefer to see a global solution which worked not only for templates, but for inline functions, class definitions, and all of the rest. --=20 James Kanze mailto:kanze@gabi-soft.fr Conseils en informatique orient=E9e objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93 --- [ 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 ]