From 4902594495003369525 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,ccbfcafab96cf493 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-12-08 13:21: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: Pete Becker Newsgroups: comp.std.c++ Subject: Re: Proposol to increase robustness of programs Date: Sat, 8 Dec 2001 21:20:25 GMT Organization: Dinkumware, Ltd Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <3C125900.53951788@acm.org> References: <3BFE97B3.91430FB1@wanadoo.fr> <3C058126.36357A00@acm.org> <3C06A0CE.E91638E8@acm.org> <3C0C1E25.1A0247AD@acm.org> <3C0D410B.7198B21D@wanadoo.fr> <3C0D4878.A86E882E@acm.org> <7dc3b1ea.0112060840.69c166cc@posting.google.com> <3C0FD9D7.8F1845C4@acm.org> <7dc3b1ea.0112070704.1d8ad50f@posting.google.com> <3C11055C.899A4886@acm.org> <7dc3b1ea.0112080650.4af0bc11@posting.google.com> X-Trace: mail2news.demon.co.uk 1007846446 mail2news:20162 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) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Date: 8 Dec 2001 18:16:03 GMT X-Accept-Language: en Lines: 45 Xref: archiver1.google.com comp.std.c++:8565 Peter Dimov wrote: > > Pete Becker wrote in message news:<3C11055C.899A4886@acm.org>... > > Peter Dimov wrote: > > > > > > What are the alternatives - in this particular case? Ignore the > > > problem and see what tests break? > > > > Yes. That's what tests are for. > > But, as I said in the previous post, I _know_ what tests will break > (or at least I know what tests ought to break. Tests sometimes have > bugs as well.) There is no need to wait and see. What I need is not > information on what will break, but information on which source lines > have to be fixed. Preferably in double-clickable form. > > "Test and see what breaks" is not that different from "Compile and see > what breaks" except that the latter reports errors earlier and > pinpoints their location with greater accuracy. At least in this > particular case. > The difference is in attitude. Compiler-produced errors are generally regarded as part of the development process, with no negative implications about the author (unless you accept Tom DeMarco's suggestion that developers shouldn't be allowed to use compilers, and if their "finished" code doesn't compile it gets logged as a bug), while test failures are tracked as bugs. Making it easy to detect some portion of a class of errors at compile-time encourages sloppiness: hack the code until it compiles, then declare it finished. What's needed is the discipline to trace the implications of the change through all of the code, not just to the places where the compiler detects a problem. -- Pete Becker Dinkumware, Ltd. (http://www.dinkumware.com) --- [ 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 ]