From 3826172917980089711 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,ccbfcafab96cf493 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-11-24 19:15:05 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!howland.erols.net!news.alt.net!comp-std-cpp-robomod!not-for-mail From: "Maarten Hilferink" Newsgroups: comp.std.c++ Subject: Re: Proposol to increase robustness of programs Date: Sat, 24 Nov 2001 21:14:55 CST Organization: Tiscali Netherlands Lines: 109 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <9to7im$1oi$1@nereid.worldonline.nl> References: <3BFE97B3.91430FB1@wanadoo.fr> Return-Path: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Trace: nereid.worldonline.nl 1006608790 1810 195.241.195.148 (24 Nov 2001 13:33:10 GMT) X-Complaints-To: newsmaster@worldonline.nl NNTP-Posting-Date: 24 Nov 2001 13:33:10 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xref: archiver1.google.com comp.std.c++:8291 "Lo�c Joly" wrote in message news:3BFE97B3.91430FB1@wanadoo.fr... ... > I would like to make a proposal for an addition to the C++ standard. > It pertains with virtual function that we want to be sure exist in the > base class. ... > Proposal : > Add something that will prevent compilation if a virtual function does > not have a function to override in the base class. > Some notation (with comments) may be : ... > override virtual void f(char *s); > I would like to know what do you think of this proposal; and if there is > something I can do to make it accepted in the next standard, I would > like to have some advise about it. Your proposal for an "override" keyword (or a "=1" suffix) at (virtual) member function declarations allows the specification of conditions on base / derived classes. I support this, as I am already using "override" for a long time in my c++ code, like in Delphi. ( in fact, I use the following defines to use "override f();" instead of "virtual f()" where appropiate, but are still waiting for supporting compilers #define override virtual #define final virtual ) To support more fine tuned and readable specification of the contractual offers and acceptance of base- and derived- classes, which will be good for the builders AND users of class-frameworks, I here propose a generalized version of your proposal (and other proposals in this direction, such as "final"). The existing suffix "=0" puts a condition on all DERIVED classes from which actual objects are constructed (which I will call implementing classes): f()=0; MUST BE overridden in any derived (constructible) class. Your proposed "override" prefix puts a condition on BASE classes: f() MUST have BEen declared (virtual) in one of the specified base classes. To generalize this and other proposals in this direction, I would like also to specifiy the opposite conditions, thus that f() MAY NOT have BEen declared (virtual) in any of the base classes; f() MUST BE an "additional" virtual, or that f() MAY NOT BE overridden any more in any derived classes (some have proposed a "final" keyword here, but the "=1" suffix seems more consistent for this purpose) This all can be summarized in the following matrix: | Implementing classes and f() | MUST HAVE | Maybe | MAY NOT HAVE, overriding f() in derived classes is forbidden --------+------+---------------------------+-------------------------+------ --------- BASE | YES | override virtual f()=0; |override virtual f(); | override virtual f()=1; CLASS | Maybe| virtual f()=0; |virtual f(); | virtual f()=1; HAS f() | NO | additional virtual f()=0; | additional virtual f(); | f(); (or additional virtual f() = 1;) Thus, the relation with base classes can be speficied by optionally using either "override" or "additional" (optinally) combined with "virtual", whereas restrictions on derived classes can be specified by the optional use of either "=0" or "=1". Additional semantic rules for overloading non-virtual functions may have to be defined. Note that conditions on the allowance of (further) derivation can be enforced by specifying the =0 or =1 conditions on the destructor. Breaking Existing Code? Existing code can be compiled on compilers that support these extensions (exept when the keywords "override" or "additional" are used as identifiers; it would help to put these keywords on a "don't use these anymore, you never know" list.) The use of the new keywords "additional" and "override" (instead of new or static); makes it possible to compile new featured code on existing compilers (by using two simple #defines). New code that uses "=1" cannot be compiled on existing compilers; but you can use defines here as Compiler-Fine-Tuning: #define CFT_ABSTR =0 #define CFT_FINAL =1 Conclusions: Although changing the standard seems to meet much resistance, I would like the above stated non-code-breaking features to be included in a future standard. Maarten Hilferink. --- [ 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.research.att.com/~austern/csc/faq.html ]