From -7994811107210807952 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,6f8a6f83898a0810 X-Google-Attributes: gidf78e5,public From: Rob Stewart Subject: Re: assert-statement (was inlining virtual functions) Date: 1996/06/15 Message-ID: <31C31EFA.28D@datalytics.com>#1/1 X-Deja-AN: 160370622 references: <2xivdn4gym.fsf@mpii01106> <4ot810$91c@newsbf02.news.aol.com> x-original-date: Sat, 15 Jun 1996 16:37:14 -0400 organization: Datalytics, Inc x-auth: PGPMoose V1.1 PGP comp.std.c++ newsgroups: comp.std.c++ originator: austern@isolde.mti.sgi.com x-mailer: Mozilla 3.0b4Gold (WinNT; I) 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'. But what about environments that aren't console-based. Consider what Microsoft provides with its Foundation Class library for MS Windows applications. They provide an ASSERT macro that produces a message box explaining that an assertion fired, and includes the filename and line number for it. If you click the Retry button, it starts the debugger for you and breaks at that point in the code. (All of this assumes that NDEBUG is not defined.) To allow for commonality between folks programming with MFC for Windows and those writing console apps, we've created a macro, DI_ASSERT which, depending upon the environment, maps to assert or ASSERT. Together, we now have three ways of writing assertions: assert(?), ASSERT(?), and DI_ASSERT(?). The compiler might be able to optimize based upon the common word, "assert," but not the others. (Never mind the fact that it's the preprocessor that does the macro expansion, so the compiler never sees "assert" anyway.) 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. That seems like a nice reason to augment the standard. -- Robert Stewart | My opinions are usually my own. Datalytics, Inc. | stew@datalytics.com | http://www.datalytics.com --- [ 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 ]