🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2642

Re: Virtual functions and destructors

#2642
From: John Max Skaller
Date: Sun, 19 Nov 1995 20:36
76 lines
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-back
References: <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)