From -7043458216087787950 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,eaeb4b8245d8b1d6 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-02-17 09:09:31 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!sn-xit-06!sn-xit-08!supernews.com!diablo.theplanet.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: danielgutson@hotmail.com (danielgutson@hotmail.com) Newsgroups: comp.std.c++ Subject: Re: proposal?: template interfaces Date: Mon, 17 Feb 2003 17:09:30 +0000 (UTC) Organization: http://groups.google.com/ Lines: 132 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <23478c42.0302131636.5ea9a6e7@posting.google.com> References: <23478c42.0302102345.244450c8@posting.google.com> <1044985656.745750@master.nyc.kbcfp.com> <23478c42.0302120612.6e9a2173@posting.google.com> <8b42afac.0302122059.116dd4fc@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1045501770 16114 10.0.0.1 (17 Feb 2003 17:09:30 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 17 Feb 2003 17:09:30 +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 18kolk-0004Bk-00 for mail2news@news.news.demon.net; Mon, 17 Feb 2003 17:09:29 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id EAA02568; Tue, 18 Feb 2003 04:09:23 +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: 14 Feb 2003 00:36:47 GMT X-Spam-Status: No, hits=-7.9 required=5.0 tests=FORGED_HOTMAIL_RCVD,NOSPAM_INC,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01 version=2.41 Xref: archiver1.google.com comp.std.c++:17980 kuyper@wizard.net (James Kuyper) wrote in message [snip] > You can't possibly cover all of the requirements of an arbitrary > template with any reasonable syntax, but I agree that there could be [snip] Ok, this is a general answer, not only for James. First, I admit you gave me feedback of many situations I didn't think about. What I wanted to go, is specifically to 'explicit' parametric polymorphism, something like class X : public Y, template Z { ... }; where you could mix both kinds (Z would be a template interface). BUT, with all your comments, I arrive that: * providing template instantiation preconditions, the compiler would become an interpreter for testing such conditions. * 'interface' compliancy is just one case inside many (as many of you mentioned). >From this point, I would give this proposal up. What follows is an invitation for a brainstorming. Whoever wanting to participate thinking that the intention of the proposal is important, is welcommed. ---End proposal-mode. ---Begin brainstorming-mode. The only syntax I can reach, but I'm not sure how acceptable is (in terms of usefullness, readability, practiceness, etcetcetc), is a new construct, a template_condition. A template condition would cover complex situation validations with boolean expressions. Let me go by steps with an open draft: first, a [i.e. class] template would look as template MyCondition? class MyClass { }; where MyCondition?<> is optional (for compatibility; its absence means 'irrestricted', in the same way it is now). Many templates could use the same condition. The condition, would look like: template_condition < typename A, typename B, int C> MyCondition { condition1; ... conditionN; }; where each condition would evaluate to a boolean expression during compile time (let me define the operands below). The implicit bool. operator is 'AND', so ALL the conditions should be accomplished. Inside each condition, parenthesis, &&, || and ! operators could nest subconditions. template_conditions would be able to inherit from other template_conditions, including all its conditions in the same 'and' fashion. The atomic condition would admit: 1) inheritance and template inheritance operator ':' 2) existance of funtions a global operators 3) relational operators for integral template parameters Deployment: 1) inheritance. If we want to ensure that a template parameter 'accomplishes' a given interface, we could write A:MyInterface (and using ',' for multiple inheritance) This would be both for template and non-template inheritance. (let's say, 'common' inheritance: base-class testing). 2) global functions/operators existance: if we want to ensure that a global function accepting the template_condition parameters exist, we could test [rettype] f(A,B,double) saying that a prototype of 'f' must exist accepting types A and B (template_condition parameters) and double. (rettype could also be specified or not; if specified, it could be a specific type, or a template_condition parameter). Same thing with operators: if we want to ensure that an operator (member or non-member) exist between A and B, we could write [rettype] A+B [rettype] A< 3 Finally, an example for MyCondition: template_condition < typename A, typename B, int C> MyCondition: ABaseCondition { (C>3 && C<10); A:MyBase1; (B:template MyTemplate2 || B:MyBase2); int A+B; myFunction(A,B); }; I think that this would cover a good set of situations. Is it adiction to complexity? Daniel. --- [ 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 ]