From 3859317740103573732 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,eaeb4b8245d8b1d6,start X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-02-11 09:07:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.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: proposal?: template interfaces Date: Tue, 11 Feb 2003 17:07:24 +0000 (UTC) Organization: http://groups.google.com/ Lines: 163 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <23478c42.0302102345.244450c8@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1044983244 14966 10.0.0.1 (11 Feb 2003 17:07:24 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 11 Feb 2003 17:07:24 +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 18idsQ-0003tF-00 for mail2news@news.news.demon.net; Tue, 11 Feb 2003 17:07:23 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id EAA29505; Wed, 12 Feb 2003 04:07:18 +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: 11 Feb 2003 07:45:37 GMT X-MailScanner: PASSED (v1.2.7 30592 h1B7jclO034693 mailbox1.ucsd.edu) X-Spam-Status: No, hits=-1.7 required=5.0 tests=FORGED_HOTMAIL_RCVD,NOSPAM_INC,SPAM_PHRASE_00_01 version=2.41 Xref: archiver1.google.com comp.std.c++:17899 Hi people, I have a concern about templates. I will write this in a form of a proposal, but maybe I�m the only concerned about this. Please let me know. Overview & motivation: When a class [for example of a library] is a template class, often it is not clear what the class will use from the template parameter. If you will provide such parameter, I would like to have a way of �seeing� what should I implement (before getting infinite complaining template instant.errors). For example, I (ashamed) admit I have no clear what should I provide as an allocator :) The idea is to �ensure� 2 things: 1) I have a clear definition about what the template class will require from the template parameter 2) The template class developer can ensure he is bounding the usage from the parameters, so changes can be controlled with a common template-interface. In other ways, it�s a legalization of parameterized inheritance. Proposal: I propose to define the a) template interface declaration (as �virtual template�, see below) b) the usage of the template interface Development: a) The template interface looks like a class declaration, with declarations of the methods, attributes and/or typedefs. It would be declarred as virtual template class Name { method_declaration1; ... method_declarationN; ...other declarations. }; This template interfaces will have neither definitions (only declarations) nor accessibility modifiers (public, protected, ...). They can inherit from other template interfaces. They can also have template parameters (i.e., be templates themselves). b) the template class. Template classes will be able to �use� the template interfaces by adding the �:� operator to their template parameters, combined with the �+� operators (see below pls.). Example: template class MyClass { ... }; meaning: MyClass will [only] use the declarations of T present in I. It will also be solved at compile time (right?) instead of linking time. So, this provides: 1. The warranty to the MyClass� user that providing all the declarations present in I will be enough for MyClass (and self-doc.) 2. the MyClass� development can be �bounded� by limiting the usage of T by I. 3. Earlier and lighter validations can be done thru forward declarations In the case that I is a template interface receiving template arguments, they can be passed using the <> : template > class MyClass { ... }; In the case that the template class uses (requires) more than one template interface for a template parameter, it can specify them thru the �+� operator: template class MyClass { ... }; so the requirements for T are: -the declarations of I1 and -the declarations of I1�s base template interface (recursively) and -the declarations of I2 and -(same recursive of base on I2) Addendums: *The following situation would be valid: template > class MyClass { ... }; *The following situation would be meaningless (and avoided?): template class MyClass { ... }; *[rule] Whenever the template interface is referred within its declarations, such type will be replaced by the template parameter type (see example at the bottom) Compatibility: As far as this is a new syntax, both declarations (template interfaces and template parameters) are invalid in current syntax. For the current template usage, we can define them as �irrestricted template parameters�, meaning that no information is provided, and should be solved during template instantiation in the same way they are solved now. (I think that they should become obsolete with this syntax). A complete example: ------------------(till the end of the message) A template interface providing an incrementor interface: virtual template Incrementor { Incrementor& operator ++(); Incrementor& operator ++(int); }; A class using it: template class X { I i; public: void inc(void) { i++; //valid } void dec(void) { i--; //invalid: operator -- not defined in Incrementor } }; void somewhere(void) { X x; //valid: int has both ++ pre/post operators struct MyStruct{}; X y; //invalid } Thanks! 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 ]