From 4181901546186768776 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,7b79e159eaf7fc79 X-Google-Attributes: gidf78e5,public Path: g2news1.google.com!news1.google.com!news.glorb.com!newsgate.cistron.nl!pop-news-1.colt-telecom.nl!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: AlbertoBarbati@libero.it (Alberto Barbati) Newsgroups: comp.std.c++ Subject: Re: Template visibility / linkage Date: Wed, 23 Jun 2004 01:21:52 +0000 (UTC) Organization: [Infostrada] Lines: 92 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <40d85d55$0$25274$9b4e6d93@newsread2.arcor-online.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: mail2news.demon.co.uk 1087953712 28586 10.0.0.1 (23 Jun 2004 01:21:52 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 23 Jun 2004 01:21:52 +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 1BcwSU-0007Qu-00 for mail2news@news.news.demon.net; Wed, 23 Jun 2004 01:21:51 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i5N1LlRR017214; Wed, 23 Jun 2004 11:21:47 +1000 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i5N1LkgM017199; Wed, 23 Jun 2004 11:21:46 +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 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en, it X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: Wed, 23 Jun 2004 01:53:07 MET DST X-Virus-Scanned: by amavisd-new at libero.it 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: g2news1.google.com comp.std.c++:986 edA-qa mort-ora-y wrote: > I am having difficulty determining what the proper linkage/locating of > templates and their specializations (Section 3.5.4 briefly mentions > template linkage, and 14 talks about the export keyword). > > Situation A: > > In : > template void func( T val ); > > In : > #include "header1" > template<> void func( int val ) { ... } > > In : > #include "header1" > .. > int a; > func( a ); > > Comments: In this situation, should the code in end up calling > the template specialization as defined in , even though it is > unaware of its existence at compile time? Since the linkage of the > template is external, and it has the same signature, I would assume yes. This code is ill-formed. Compiling triggers an implicit instantiation of the function template func, so either the definition of the primary template shall be visible or the template shall be declared with the export keyword. A non-exported declaration (as in the example) is not enough. The presence of the specialization in is inessential to this example. The fact that the linkage of a template is external is completely unrelated with this example. > > Situation B: > > In : > template void func( T val ) > { /* primary def */ } > > In : > #include "header1" > template<> void func( int val ) ... > > In : > #include "header1" > .. > int a; > func( a ); > > Comments: Should the code in use the primary template definition > or should it use the specialization from ? My reading of the > standard indicates it should use the specializaed form, since the > template matching doesn't appear to be limited to the current > translation unit, and the the function signature will match that in > at link time. This code is ill-formed too. In 14.7.3/6 it is clearly stated that: "If a template [...] is explicitly specialized then that specialization shall be declared before the first use of that specialization that would cause an implicit instantiation to take place, in every translation unit in which such a use occurs; no diagnostic is required." > > I am unclear of whether the template matching rules hold over to link > time, or only for the current translation unit. That is, if , in > both cases, were to also include it would be clear that it usese > the specialization, but since it doesn't include , the compilation > finishes without knowledge of the specialization. Does the linker then > /do the right thing/? > The above statement leaves no doubt to me. If does not include the program is ill-formed. > And I'm completely unclear on classes, whether they should match > identical declarations in other units, as there would be signifcant > sizing problems for the compiler. Though I can't see why it would be > disallowed according to the standard. > The same argument applies to class templates. Alberto --- [ 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 ]