From 5295545761214894505 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,eaeb4b8245d8b1d6 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-02-13 08:41:59 PST Path: archiver1.google.com!news2.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: kuyper@wizard.net (James Kuyper) Newsgroups: comp.std.c++ Subject: Re: proposal?: template interfaces Date: Thu, 13 Feb 2003 16:41:50 +0000 (UTC) Organization: http://groups.google.com/ Lines: 59 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <8b42afac.0302122059.116dd4fc@posting.google.com> References: <23478c42.0302102345.244450c8@posting.google.com> <1044985656.745750@master.nyc.kbcfp.com> <23478c42.0302120612.6e9a2173@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1045154510 6725 10.0.0.1 (13 Feb 2003 16:41:50 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 13 Feb 2003 16:41:50 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 18jMQl-0001kK-00 for mail2news@news.news.demon.net; Thu, 13 Feb 2003 16:41:48 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id DAA19113; Fri, 14 Feb 2003 03:41:44 +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++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: 13 Feb 2003 04:59:06 GMT X-MailScanner: PASSED (v1.2.7 19011 h1D4x6O6031929 mailbox2.ucsd.edu) X-Spam-Status: No, hits=-4.3 required=5.0 tests=MEMBER_2,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Xref: archiver1.google.com comp.std.c++:17937 danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message news:<23478c42.0302120612.6e9a2173@posting.google.com>... > hyrosen@mail.com (Hyman Rosen) wrote in message news:<1044985656.745750@master.nyc.kbcfp.com>... > > danielgutson@hotmail.com wrote: > > > often it is not clear what the class will > > > use from the template parameter. > > > > The problem is that usage in templates cannot be covered > > by simple method requirements. For example, if I write > > > > template > > OS &print(OS &os, const T &t) > > { return os << t; } > > > > what kind of requirements could you give for OS and T > > virtual template OsInterface > { > OsInterface& operator << (const T& t); > }; I'm not entirely clear on the notation, but that looks to me like it's specifying that the applicable operator<<() must be a member function of OS. Is it in fact intended to prohibit the possibility of using a non-member function? How about an operator<<() that matches both OS and T only after implicit type conversion? Koenig lookup? You can't possibly cover all of the requirements of an arbitrary template with any reasonable syntax, but I agree that there could be some value in providing compile-time checking of the ones that can be specified. However, I'd say that the most reasonable way to specify the requirements would be to provide a list of example statements that must be syntactically valid, in order for the template instantiation to succeed. For most functions, the function body itself would qualify as that list. Therefore, we already have this feature, as far as inline functions are concerned. However, there would be some value in a seperate specification, for several reasons: 1) The requirements specification might be much shorter than the code itself. 2) The requirements specification would be part of the template declaration; it would be present even if the template's definition is exported to a different translation unit. 3) The specification would list the requirements that are intended to apply, rather than the ones that are actually imposed by the implementation of the template. This could be useful if the shorter size of the specification means it's more likely to be correct, which means it can be used to validate the template's actual implementation. A compiler could automatically check to see if that implementation implies any requirements that aren't in the specification, or is inconsistent with any of the specified ones. --- [ 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 ]