From 7313772773549751183 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,ccbfcafab96cf493 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-11-27 11:13:01 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!supernews.com!194.159.255.21.MISMATCH!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: Tue, 27 Nov 2001 19:12:13 GMT Organization: Dinkumware, Ltd Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <3C03E02E.FA9754A3@acm.org> References: <3BFE97B3.91430FB1@wanadoo.fr> <3C02E8F1.4BDAAF29@acm.org> X-Trace: mail2news.demon.co.uk 1006888339 mail2news:29193 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=iso-8859-1 NNTP-Posting-Date: 27 Nov 2001 18:48:53 GMT X-Accept-Language: en Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id GAA01971 Lines: 61 Xref: archiver1.google.com comp.std.c++:8323 Francis Glassborow wrote: >=20 > In article <3C02E8F1.4BDAAF29@acm.org>, Pete Becker > writes > >Lo=EFc Joly wrote: > >> > >> This works just fine, but now, suppose someone in charge of maintain= ing > >> the A class discovers that the declaration of f should have been : > >> virtual void f(char const *s); > >> He makes the change, but somehow forget to change class B. The compi= ler > >> will compile silently, but the program will not do the expected thin= g. > >> This is a real-world example that has already bitten me several time= s, > >> and is difficult to debug. > >> > > > >You should complain to the person who made that change without > >understanding and documenting its implications. Adding a virtual > >function to a class (whether that's a consequence of adding a new > >function or changing an existing one) is a drastic change, and users o= f > >the class should be alerted to it. >=20 > You mean like the way that the Standard encourages implementors to tell > users about adding parameters to functions (thereby changing their > signatures, and possibly altering overload resolution when assigning to > a pointer to member? :-) The standard neither encourages nor discourages this. It allows implementors to add parameters with default values to non-virtual member functions. Professional programmers know this, and don't assume that they know the exact signature of such functions. So, to answer your question, no, it has nothing to do with what the standard says. Programmers who maintain classes that are designed to be derived from must be sure they understand the consequences of any interface changes they make, and must document those changes. >=20 > Unfortunately we live in a far from perfect world. It is a good idea to > check that the cars have actually stopped before stepping onto a > pedestrian crossing. >=20 Obviously, when you get an upgraded library you check the documentation to see if any of the changes affect your code. --=20 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 ]