assert(condition[, message]) patch

[Derek Parnell]

On Wed, 31 May 2006 23:12:42 -0700, kris wrote:

> I wish I could understand why this is needed in Build, Derek ... Build 
> is truly great, at what it does well. Now it apparently allows one to 
> intimately tie their code to Build, for all eternity, by extending the D 
> language? Does this new stuff slow it down even a tiny bit?
> 
> Sorry if this comes off a bit negative, but Build is just so good as it 
> is. Still, it is your baby :)

Not at all! I love to hear real users' feedback. 

Rest assured though that from a performance point of view, you won't notice
anything if you aren't using this facility, because it doesn't do text
preprocessing on ".d" files. Instead you have to explicitly use ".mac"
files which are transformed into ".d" files. However in the end, you are
not forced into using the text processing stuff, just like you are not
forced into using 'goto'.

One reason for extending Build is so I can use it to build things other
than D applications. But I've kept in mind the 'normal' case of using it
with D so that is where the performance bias is.

But there will now be a few milliseconds extra delay at start up time
because I've replaced a lot of hard-coded strings with user-definable ones,
which are cached when the program starts.


------
I just had a bit more of a go at an 'assert' macro and it can actually do
this ...

  regexp assert\((.*),(.*)\);   = 
       if (!($1)) {writefln(`%%s:%%s`, `$1`, $2); assert(0);}

used as ...

    assert(result != 0, "Bad result");

and comes out as ...

   if (!(result != 0)) {writefln(`%s:%s`, `result != 0`,  "Bad result");
assert(0);}


So Walter, if you want to stop this nasty abomination of source code abuse,
please allow coder defined messages in the built-in assert statement ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
1/06/2006 4:20:39 PM