Assertions via assert.h (or cassert) are disabled in production and
have to be enabled via the NDEBUG macro. This is one reason I don't
use the assert macro. I always throw an exception that means a fatal
programming error has occurred. Am I the only one that does this?
Surely not. My reasoning is that I always want the checks on, just in
case. This means it is something I tend to do sparingly, after all,
loads of them might well create a performance issue.

All the std programming text tell us how good it is to use assertions
(I am thinking of books like OOSC(II)) but the mechanism they describe
is like cassert every time, i.e turned off in production. I have
noticed that it is hardly ever used on any C++ projects I have seen.
It doesn't seem to get much use in C libraries either but does seem to
have a slightly higher usage there.

Does this mean C++ programmers don't like such a C-like mechanism? Or
they don't don't like the fact that the assertions are disabled in
production? Or is there some other reason?

Regards,

Andrew Marlow

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 4, 10:13 pm, marlow.and...@googlemail.com wrote:
> Assertions via assert.h (or cassert) are disabled in production and
> have to be enabled via the NDEBUG macro.

Incorrect. It is common in my experience to leave assertions enabled
all throughout a program's development, sometimes even when it ships
(this is more common when a product is shipped internally, ie: not for
retail).

In any case, NDEBUG disables the assert macro: it does not enable it
as you said.

> This is one reason I don't
> use the assert macro. I always throw an exception that means a fatal
> programming error has occurred. Am I the only one that does this?
> Surely not. My reasoning is that I always want the checks on, just in
> case. This means it is something I tend to do sparingly, after all,
> loads of them might well create a performance issue.

This is bad programming practice. An exception should be thrown when
there is a reasonable chance that it will be handled, or to
intentionally propagate failure to the highest level (usually a top-
level handler of some kind). This doesn't characterize many
situations: for example, validating pre-conditions of a method or
function is much-better suited to an assert. It's local to the point
of failure, potentially allows continuation (for debugging), and has a
more concise syntax than a condition test + throw statement. Note that
it's also common to use custom assertion macros that throw exceptions
on failure (this is often used in Unit Testing frameworks): the two
are not mutually exclusive.

> All the std programming text tell us how good it is to use assertions
> (I am thinking of books like OOSC(II)) but the mechanism they describe
> is like cassert every time, i.e turned off in production. I have
> noticed that it is hardly ever used on any C++ projects I have seen.
> It doesn't seem to get much use in C libraries either but does seem to
> have a slightly higher usage there.

Assertions are not used enough because overall people code badly. If
you're throwing exceptions around instead of wrapping your simple pre-
and post-conditions into a simple assertion macro (whether that macro
throws an exception or not, and regardless of the conditions under
which it's enabled or not), then I submit that you're also coding
badly.

> Does this mean C++ programmers don't like such a C-like mechanism? Or
> they don't don't like the fact that the assertions are disabled in
> production? Or is there some other reason?

It's tough to answer what all or most or many or any C++ programmers
like or don't like. A problem that emerges with C++'s flexibility is
that it doesn't enforce much rigor. For example, if you contrast C++
with, say, Eiffel, you will notice that Eiffel places more emphasis on
logical rigor by simplifying Design By Contract.

I suggest that you learn and apply best practices in the language that
you work in, and learn other languages and their best practices to
round out your knowledge. It's good to look at other people's code,
but it's better to look at the very best examples - you will probably
notice a much higher degree of assertion checking in such code.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

> Does this mean C++ programmers don't like such a C-like mechanism? Or
> they don't don't like the fact that the assertions are disabled in
> production? Or is there some other reason?

I have faced this situation several times in the past. In the end I decided
that if I could not bring myself to turn off the Assertions then I was
implying that the code was not robust. I don't tend to use assertions very
often these days and tend to throw exceptions on bad inputs, in cases where
the scope for error is high and the scope for a "catastrophic outcome" is
real (eg. a crash, as opposed to simply computing an invalid result).

What is your definition of a programming contract, in terms of an API? Some
people think every function should check all the arguments and throw
graceful exceptions if you violate the contract. This acts like a Guard at
the door.

Others think that violation of the contract leads to violation in terms of
the operational behaviour (eg. a crash or whatever) and if you hadn't
violated the contract you wouldn't get the crash. This is the Garbage in,
Garbage Out principle.

The practical upshot is that one viewpoint puts the onus on the API writer
to check their arguments, and the other puts somewhat of an onus on the
caller to check their arguments.

I don't think a blanket statement works either way. High-performance code
cannot afford to check every argument to ensure it is getting the right
arguments every time - because that would be detrimental to performance.



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

> Does this mean C++ programmers don't like such a C-like mechanism? Or
> they don't don't like the fact that the assertions are disabled in
> production? Or is there some other reason?

>From my experience over the years, programming with some
basic properties like structuring, documenting, using
design pattern, recognizing anti pattern and using a
good error handling is a matter of discipline!
It's a big topic!

Most developers do not have that discipline.
In addition - the companies managements are forcing quick
solution for the lack od software quality.
It's a big topic too!

Assert mechanism are important! No doubt!
In production code you have to be aware of situation
which can fail and the code still shouldn't crash!
The next example easily demonstrates the problem with
production code:
---
bool check(Data* data)
{
assert(data);
return data->isValid();
}
---
A little better:
---
bool check(Data* data)
{
assert(data);

if (data)
return data->isValid();
return false;
}
---

I hope it helps a little.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 5, 2:13 pm, marlow.and...@googlemail.com wrote:
> Assertions via assert.h (or cassert) are disabled in production and
> have to be enabled via the NDEBUG macro. This is one reason I don't
> use the assert macro. I always throw an exception that means a fatal
> programming error has occurred. Am I the only one that does this?
> Surely not. My reasoning is that I always want the checks on, just in
> case. This means it is something I tend to do sparingly, after all,
> loads of them might well create a performance issue.
>
> All the std programming text tell us how good it is to use assertions
> (I am thinking of books like OOSC(II)) but the mechanism they describe
> is like cassert every time, i.e turned off in production. I have
> noticed that it is hardly ever used on any C++ projects I have seen.
> It doesn't seem to get much use in C libraries either but does seem to
> have a slightly higher usage there.
>
> Does this mean C++ programmers don't like such a C-like mechanism? Or
> they don't don't like the fact that the assertions are disabled in
> production? Or is there some other reason?
>

I think you [possibly] misunderstand the fundamental rule
for assertion usage. That is,

" Use assertions for conditions that should *never* occur, and
use error handling code for conditions you expect to occur. "

If you always want the checks on, that means the conditions you
checked are expected to occur during run-time. Therefore, yes,
it is not necessary to use assertion here, just handle them and
everything will be fine. Define the possible errors and categorize
them for assertion/error-handling is the first thing you should do
for your defensive code.

[ "how good it is to use assertions" are snipped . ]

And the macro disable issue:
For the standard assert macro, it is specified in C standard
that assert shall refer to NDEBUG, and C++ borrow this
rule from C. There is no like/dislike issue at all, since the
underlying assert macros are same. If you don't like it,
write your own assertion handlers.

BTW, it is not unusual that both assertion and error handling
are used together to make the code safer. That is, although
only one of them should be sufficient, instead of using
standard assert, you can enable and handle your own
assertions during run time (of course you need install your
special assertion handlers), well, lets say for mission-critical
code.

Jiang


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 2008-08-05 07:13, marlow.andrew@googlemail.com wrote:
> Assertions via assert.h (or cassert) are disabled in production and
> have to be enabled via the NDEBUG macro. This is one reason I don't
> use the assert macro. I always throw an exception that means a fatal
> programming error has occurred. Am I the only one that does this?
> Surely not. My reasoning is that I always want the checks on, just in
> case. This means it is something I tend to do sparingly, after all,
> loads of them might well create a performance issue.
>
> All the std programming text tell us how good it is to use assertions
> (I am thinking of books like OOSC(II)) but the mechanism they describe
> is like cassert every time, i.e turned off in production. I have
> noticed that it is hardly ever used on any C++ projects I have seen.
> It doesn't seem to get much use in C libraries either but does seem to
> have a slightly higher usage there.
>
> Does this mean C++ programmers don't like such a C-like mechanism? Or
> they don't don't like the fact that the assertions are disabled in
> production? Or is there some other reason?

Personally I have nothing against keeping the assertions in even in the
production code. After all if your code works correctly you will never
hit an assertion but if there are they can be very useful when the
customer reports the error.

The advantage of assertions it that they give you the file and line
where the error occurred for free. You can get the same information with
exceptions, and if you put some effort into it you can probably get a
stack trace also.

As for performance, I would not worry about it, after all you should
only assert things that are not supposed to happen and which can not
gracefully be handled. There should not be too many of these.

--
Erik Wikström


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

marlow.andrew@googlemail.com wrote:
> Assertions via assert.h (or cassert) are disabled in production and
> have to be enabled via the NDEBUG macro.

Sorry, but that is wrong: You have to disable (not enable!) assertions with
the NDEBUG macro. Further, whether that is done in production code is up to
personal taste. I like them off in my production builds though, because I
need the speed more than the absolute correctness of the result, but I
don't program medical equipment or aviation devices either.

> This is one reason I don't use the assert macro. I always throw an
> exception that means a fatal programming error has occurred. Am I the
> only one that does this?

How do you throw exceptions from a destructor? How do you throw them from a
signal handler or thread entry function which has C binding and therefore
must not throw? In any case, you are neither aborting cleanly nor are you
unwinding the stack to a place where the state is valid again. After all,
detecting a programming error, an unexpected inconsistency often means the
state of the program is beyond repair, so anything that still touches it
(like throwing exceptions) is likely to not make it better.

Also, but I don't know if you meant that, an exception doesn't automatically
mean a fatal programming error has occurred, exceptions are a perfectly
normal part of error handling.

> My reasoning is that I always want the checks on, just in case. This
> means it is something I tend to do sparingly, after all, loads of them
> might well create a performance issue.

Right, lots of checks can create performance issues. However, you shouldn't
handle this as error handling but rather as a built-in diagnostic mode for
your code. For example, I have a parser table and my algorithm uses a
binary search that obviously relies on the table being sorted. Now, I don't
check each and every time when I look up a value that the keys are sorted.
Rather, I only do so when NDEBUG is not defined. The point is simply that I
am confident that the production and debug variants work the same, but in
the debug variant I check this using alternative algorithms or expensive
validation. You could call this a built-in unit test.

> All the std programming text tell us how good it is to use assertions
> (I am thinking of books like OOSC(II)) but the mechanism they describe
> is like cassert every time, i.e turned off in production. I have
> noticed that it is hardly ever used on any C++ projects I have seen.
> It doesn't seem to get much use in C libraries either but does seem to
> have a slightly higher usage there.

Well, lots of bad code are out there, in particular for languages that make
it damn easy to shoot yourself in the foot like C and C++. That is IMHO not
a reason why the language or in this case assertions are a failure, it's
just that people don't understand assertions or that they don't understand
their value.

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 5 août, 07:13, marlow.and...@googlemail.com wrote:
> Assertions via assert.h (or cassert) are disabled in production and
> have to be enabled via the NDEBUG macro.

That's the opposite. Assertions are enabled unless you define NDEBUG
(no debug).
The rationale for that is that assertions are for programming errors,
and those errors have no reason to happen in a valid program. Once
you've tested your program enough, or performed enough static
analysis, you should be able to tell whether your program is valid or
not and never invokes those programming errors.
Only in that case are you to disable assertions, since you have
demonstrated they were never fired and thus introduced useless
overhead.


> I always throw an exception that means a fatal
> programming error has occurred.

There is a big problem in this sentence.
A fatal programming error is not a recoverable exception. Throwing an
exception (which is to be caught) doesn't make sense. You should abort
the program.


> Am I the only one that does this?
> Surely not. My reasoning is that I always want the checks on, just in
> case.

Simple: do not define NDEBUG in your release builds.
That kinda means you clearly expect your program not to be robust,
though.


> Does this mean C++ programmers don't like such a C-like mechanism? Or
> they don't don't like the fact that the assertions are disabled in
> production? Or is there some other reason?

The C++ type system allows static assertions and types that always
satisfy some invariants.
This diminishes the need for runtime assertions.

Unfortunately, there are also a great deal of people that are using
exceptions for case that really ought to be assertions.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

marlow.andrew@googlemail.com wrote:
> Assertions via assert.h (or cassert) are disabled in production and
> have to be enabled via the NDEBUG macro. This is one reason I don't
> use the assert macro. I always throw an exception that means a fatal
> programming error has occurred. Am I the only one that does this?
> Surely not. My reasoning is that I always want the checks on, just in
> case. This means it is something I tend to do sparingly, after all,
> loads of them might well create a performance issue.
>
> All the std programming text tell us how good it is to use assertions
> (I am thinking of books like OOSC(II)) but the mechanism they describe
> is like cassert every time, i.e turned off in production. I have
> noticed that it is hardly ever used on any C++ projects I have seen.
> It doesn't seem to get much use in C libraries either but does seem to
> have a slightly higher usage there.
>
> Does this mean C++ programmers don't like such a C-like mechanism? Or
> they don't don't like the fact that the assertions are disabled in
> production? Or is there some other reason?

An assertion is a useful low-level mechanism for catching bugs near
where they live, rather than waiting until 100000 cycles later when the
error shows up someplace else.

In production code, you work really hard to ensure that the user doesn't
lose data. That means that you don't make the program spew its guts up
if it finds a zero-length string in a dialog box, say, or can't find
enough file handles to open a logfile. Those are great places for
assertions, or some similar C++ mechanism, precisely because you want to
catch them in development but ignore them or handle them gently in
production. The same is generally true of checking class invariants.

There are also lots of runtime checks that you do want to have in
production code (including some of the same ones as you'd put in
assertions), but you don't use assert() for that--if the user's data is
at stake, it's really really bad manners to call abort(). I'd chuck a
program like that in the bitbucket instantly.

Cheers,

Phil Hobbs

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 5 août, 16:28, Thomas Lehmann <t.lehm...@rtsgroup.net> wrote:

> The next example easily demonstrates the problem with
> production code:
> ---
> bool check(Data* data)
> {
> assert(data);
> return data->isValid();}
>

The real question here, is why are you even taking a pointer?
And why isn't the code const-correct?

bool check(const Data& data)
{
return data.isValid();
}

No need to assert anything.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]