Article View: comp.std.c++
Article #2642Re: Virtual functions and destructors
From: John Max Skaller
Date: Sun, 19 Nov 1995 20:36
Date: Sun, 19 Nov 1995 20:36
76 lines
3521 bytes
3521 bytes
Dick Menninger <Dick.Menninger@daytonoh.attgis.com> wrote: >Actually, "undefined behavior" is a precisely >defined term in the WP, and not just a vague >common term. No. "behaviour" is a precisely defined term. The WP proceeds to _define_ the SET of possible behaviours which a given program must have if compiled by a conforming translator. By default, the set is the universal set. Each case in the WP for which undefined behaviour is stated is REDUNDANT, and is there only to indicate completeness, or make the English more comprehensible. >In general, the application of this term to >situations by the committee is based on the >situation being potentially too hard to diagnose >in some of its manifestations. Yes. But that's the rationale for NOT defining the behaviour as a subset of the universal set. >There is a commonsense "shall" where these >situations are concerned. The programmer >shall avoid these situations like the plague >because the compiler will invariably do the first >of the three permissible behaviors and not help >detect it (Murphy's Law is they do not detect >your case, whatever it is). The point is that the CONFORMANCE TESTER shall avoid these situations like the plague because submiting a program which exhibits "undefined behaviour" provides no opportunity for measuring if the compiler is conforming or not -- and so it's a waste of time. On the the other hand the conformance tester had better submit a substantial suite of programs to the compiler, all of which are ill formed, to check if it issues mandatory diagnostics. You might think that "ill formed" and "undefined behaviour" were equivalent to the programmer, but you'd be wrong: writing ill formed code is fine, because the compiler is sure to catch it. (I do this deliberately all the time). If the compiler doesn't catch it, it isn't your fault -- complain to your vendor! But you have to watch out very very carefully for writing code with undefined behaviour. Because if your hard disk gets wiped in that case it's your fault. (yes, this HAS happened to me once :-) So the difference is in who has the responsibility for detecting the fault. [Products exist which take over some of these responsibilities (eg memory leak detectors, array bounds checkers, etc)] -- John Max Skaller voice: 61-2-566-2189 81 Glebe Point Rd fax: 61-2-660-0850 GLEBE NSW 2037 email: maxtal@suphys.physics.oz.au AUSTRALIA email: skaller@maxtal.com.au --- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu. Contact address: std-c++-request@ncar.ucar.edu. The moderation policy is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID:
<48n9vf$jjk@oznet03.ozemail.com.au>Path:
arc1-ca.pugleaf.net!cs.mu.OZ.AU!bounce-backReferences:
<480ksh$9lb@oznet03.ozemail.com.au> <DHzqpv.HF8@falcon.daytonoh.attgis.com>Show Full Headers
Complete Article Headers
Newsgroups: comp.std.c++ Path: arc1-ca.pugleaf.net!cs.mu.OZ.AU!bounce-back From: John Max Skaller <maxtal@suphys.physics.su.oz.au> Subject: Re: Virtual functions and destructors Message-ID: <48n9vf$jjk@oznet03.ozemail.com.au> Originator: fjh@munta.cs.mu.OZ.AU Sender: news@cs.mu.OZ.AU (CS-Usenet) Organization: MAXTAL References: <480ksh$9lb@oznet03.ozemail.com.au> <DHzqpv.HF8@falcon.daytonoh.attgis.com> X-Original-Date: 19 Nov 1995 13: 03:43 GMT Date: Sun, 19 Nov 1995 20:36:18 GMT Approved: fjh@cs.mu.oz.au X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBMK+VTOEDnX0m9pzZAQFokwF/Zlc3iLMX9UyjjiNQg+PQIjv4bk9fMQR9 txioJ2E1h2xAcKYQfH1M1UhmMfbfsTwy =RuMu X-Mailer: Mozilla 1.2N (Windows; I; 16bit)