--On Wednesday, November 10, 2004 3:29 AM +0000 Julian Foad
<julianfoad@btopenworld.com> wrote:
> My reasons were:
>
> 1) Consistency: we should use one or the other, with few exceptions.
> 2) Informative message when the condition arises.
> 3) Neatness (tidiness) of source code.
> 4) Not checking for bugs while running a release build.
>
> Reason (4) is strongly contested by Brane and, in case his point of view
> should be dominant, I have a partial solution that achieves the rest of
> my aims.
I'm 100% with Brane. Not enforcing assert() on a release build is *bad*
practice in the manner which we use assert()s. In fact just today, in the
class I'm TAing this quarter (Intro to SW Eng.) to 2nd year CS majors, we
just told the students that you always want to ensure correctness even in a
release build. It's not acceptable to do checks only in a debug build:
it's how bad things happen.
> Let me propose to use "verify" instead of "assert", where "verify" is
> defined to be the same as "assert" except that it is always enabled (i.e.
> even when NDEBUG is defined). This will achieve points (1), (2) and (3),
> and will leave the checks active all the time.
>
> Would this be acceptable to everyone?
I'm not sure how you'd have it defined to be the same. The expansion of
assert() is different on each platform, IIRC. But, if you satisfy the
requirement that the checks always occur, then I'd only be +0.5 just
because I think it's a lot of turmoil for little actual benefit. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 10 21:05:57 2004