From -709658381148845861 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,ccbfcafab96cf493 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-12-08 08:55:01 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!dispose.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: pdimov@mmltd.net (Peter Dimov) Newsgroups: comp.std.c++ Subject: Re: Proposol to increase robustness of programs Date: Sat, 8 Dec 2001 16:54:13 GMT Organization: http://groups.google.com/ Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <7dc3b1ea.0112080716.424f82e3@posting.google.com> References: <3BFE97B3.91430FB1@wanadoo.fr> <3C058126.36357A00@acm.org> <7dc3b1ea.0111300954.186f1ff5@posting.google.com> <3C094998.F387ABB1@acm.org> <7dc3b1ea.0112040358.1ab543ba@posting.google.com> <3C0D2BD7.C58D005E@acm.org> <7dc3b1ea.0112051131.3256045@posting.google.com> <3C0F84A6.8FBD9D12@acm.org> <7dc3b1ea.0112070658.646ff219@posting.google.com> <3C110711.140411EB@acm.org> X-Trace: mail2news.demon.co.uk 1007830458 mail2news:17945 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au 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) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit NNTP-Posting-Date: 8 Dec 2001 15:16:49 GMT Lines: 63 Xref: archiver1.google.com comp.std.c++:8564 Pete Becker wrote in message news:<3C110711.140411EB@acm.org>... > Peter Dimov wrote: > > > > OK, I can agree with this. It follows that a reasonable test set is > > difficult to get right. > > Yes, which is why testing should be left to professionals, not to > moonlighting developers. But that's a separate discussion. For the purposes of this discussion, let's label the moonlighting developers "group #2". ;-) > > It's the other way around. I've never had this kind of problem > > _because_ I spend expensive programmer time checking for it. A time I > > prefer to spend on other, more productive, things. > > I must have overlooked the place where you said that you had actually > found such problems often enough to justify looking for them. Yep. Memory is a funny thing. I don't recall having this kind of problem but I must have had it, or observed someone else having it, or simply thought about it and its potential costs. Actually now that I think about it, I _have_ had this problem. Except that the base virtual was pure, so the compiler caught it immediately. I don't know whether this qualifies. > > Because "need" and "would benefit from" aren't necessarily the same > > thing. Let's assume for a moment that C++ does have 'override.' Would > > you not use it? > > Probably not. It doesn't add anything significant. I don't believe you. ;-) You're a professional. There is no reason to deliberately avoid a (useful) tool that is part of the language. The funny thing about 'override' is that, IMO, it doesn't have any significant drawbacks. It's intuitive, clear, can be easily explained to novices, doesn't add any substantial complexity, cannot be misused. Even the universal counterargument doesn't quite apply to it. > More important, I > wouldn't recommend it to inexperienced programmers because it would be > too hard to explain why some signatures can be checked and some can't, > and that signature checking (either in the form of code reviews or in > the form of tests) must be done even if you use override. Ah, the universal counterargument. ;-) False sense of security. I think, however, that 'override' is so clear and problem-specific that even novices will immediately recognize the exact form of security that it offers. -- Peter Dimov Multi Media Ltd. --- [ 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 ]