How about a construct such as this:
assert(lines == 3, "Expected to have found three lines");

Without the message, one needs the source code to find out what the failed assertion means.

Thanks !
François

In article <ce3kob$1d6f$1@digitaldaemon.com>, Francois Beausoleil says...
>
>How about a construct such as this:
>assert(lines == 3, "Expected to have found three lines");
>
>Without the message, one needs the source code to find out what the failed assertion means.

Personally, I like having to go to the source code.  Assertions taken out of context could mean nearly anything.

Sean

In article <ce3kob$1d6f$1@digitaldaemon.com>, Francois Beausoleil says...
>
>How about a construct such as this:
>assert(lines == 3, "Expected to have found three lines");
>
>Without the message, one needs the source code to find out what the failed assertion means.

One needs the source code to fix the bug anyway - however, there might be circumstances where it becomes useful. Suppose a third party implements this function in a library:

#    int f(int n)
#    in
#    {
#        assert(n <= 10);
#    }
#    body
#    {
#        // whetever
#    }

Now, if you call this function with f(1000), you're going to get an assert - but in this case the bug is in /your/ code (because you have violated the function's in-contract). And yet, because this is a third-party library, it is possible that you might not have access to its source code. How, then, are you to know what f's contract is?

I think it was Ben who said that in-contracts are (should be) part of a function's interface. I don't know if it's possible to specify just the in-contract in a stripped down header file, but if it is, that's the way to go - in which case, you /still/ don't need an extra text message.

Arcane Jill

On Mon, 26 Jul 2004 19:06:51 +0000 (UTC), Francois Beausoleil wrote:

> How about a construct such as this:
> assert(lines == 3, "Expected to have found three lines");
> 
> Without the message, one needs the source code to find out what the failed assertion means.
> 

I think that asserts are meant to be read by the coder - the user of the source code. This doesn't mean that the coder wouldn't appreciate the _hint_ text, but they should also have access to the source.

It would be unusual to have assert messages coming out from a library that has been distributed by somebody else, except if they also distributed a special _debug_ version of the library.

-- 
Derek
Melbourne, Australia
27/Jul/04 10:05:36 AM