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 <cassert>'
> 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
]

In article <31C31EFA.28D@datalytics.com>, Rob Stewart
<stew@datalytics.com> 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 <cassert>'
> > statement.)
> >
> > In effect, you don't need an `assert-statement'.
>
> <snip>
>
> 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
]