From -3804084845072178628 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,6f8a6f83898a0810 X-Google-Attributes: gidf78e5,public From: bobh@hablutzel.com (Bob Hablutzel) Subject: Re: assert-statement (was inlining virtual functions) Date: 1996/06/17 Message-ID: #1/1 X-Deja-AN: 160654259 references: <2xivdn4gym.fsf@mpii01106> <4ot810$91c@newsbf02.news.aol.com> <31C31EFA.28D@datalytics.com> x-original-date: Mon, 17 Jun 1996 06:41:15 -0400 organization: Hablutzel Consulting x-auth: PGPMoose V1.1 PGP comp.std.c++ newsgroups: comp.std.c++ originator: austern@isolde.mti.sgi.com In article <31C31EFA.28D@datalytics.com>, Rob Stewart wrote: > Raja R Harinath wrote: > > > > lippin@svcdudes.com (Tom Lippincott) writes: > > > This brings up an interesting point: if assertions were a proper part of > > > the language, a darned smart compiler could find this optimization by > > > itself. I imagine an assert-statement: > > > > > > assert expression; > > > > > > with five rules: > > > > > > 1. The expression must have type (or be convertible to) bool. > > > 2. Whether or not the expression is evaluated is implementation dependent. > > > 3. If the expression is unevaluated, the assert-statement has no effect. > > > 4. If the expression evaluates to true, the assert-statement has no > > > further effect. > > > 5. If the expression evaluates to false, the assert-statement has > > > implementation dependent behavior. > > > > Since `assert' is part of the standard library, it is pretty much a > > proper part of the language. That means that compilers can derive any > > amount of information reasonable from the use of `assert' in the absence > > of NDEBUG (all this smarts being turned on by the `#include ' > > statement.) > > > > In effect, you don't need an `assert-statement'. > > > > Now, if there was a standard assert-statement, and a standard assertion > handler function call interface, with, say, an "assert_handler" function > call to point to your own handler function, an environment could provide > default behavior that a developer could override if desired. > Furthermore, Microsoft's assertion handling, with the dialog box and > debugger invocation, etc., could be done with their assert_handler > function. Regardless of environment, we could code "assert expression" > instead of "assert(expression)" or "ASSERT(expression)" and our code > would produce the desired result. > There is the additional problem that assert() does not unwind the stack - a real problem if you have stack-based objects that are monitoring unique system resources. However, I still don't think the standard _needs_ augmenting (not that it would not be nice). Rather, we've defined a standardized exception class with a static member function that mimics assert, except that it throws an exception rather than using assert(). This allows for the application to capture the exception and post a message in whatever manner is appropriate, while still unwinding the stack properly. Bob Bob Hablutzel Hablutzel Consulting EMail: bobh@hablutzel.com Phone: 603 431-5074 Fax: 603 431-0466 --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]