The following statement

            assert(0 == strcmp(&path[2], pathCheck));

asserts, but does not print out the values of path and pathCheck. It would be nice to know what they are. (Maybe I need a debugger!)

Someone mentioned a richer assert recently. I'm now convinced.

Ideas?

"Matthew Wilson" <matthew@stlsoft.org> escreveu na mensagem news:bm618c$3118$1@digitaldaemon.com...
> The following statement
>
>             assert(0 == strcmp(&path[2], pathCheck));
>
> asserts, but does not print out the values of path and pathCheck. It would be nice to know what they are. (Maybe I need a debugger!)
>
> Someone mentioned a richer assert recently. I'm now convinced.
>
> Ideas?

In Eiffel it's common to dump all the stack values when a contract fails, so you can see the entire call stack, local variables and bound parameters.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 7/10/2003

"Matthew Wilson" <matthew@stlsoft.org> a écrit dans le message news: bm618c$3118$1@digitaldaemon.com...
> The following statement
>
>             assert(0 == strcmp(&path[2], pathCheck));
>
> asserts, but does not print out the values of path and pathCheck. It would be nice to know what they are. (Maybe I need a debugger!)
>
> Someone mentioned a richer assert recently. I'm now convinced.
>
> Ideas?

What about :

assert(
  ( 0 == strcmp(&path[2], pathCheck) ) &&
  printf("'%.*s' and  '%.*s' are not equal",&path[2],pathCheck)
);

or maybe a alternative assert syntax :

assert( expression ; string_expression );

where String expression become the AssertException's message.

assert(
  0 == strcmp(&path[2], pathCheck);
  "'" ~ &path[2] ~ "' and  '" ~ pathCheck ~ "' are not equal"
);

-- Nicolas Repiquet

Matthew Wilson wrote:

>The following statement
>
>            assert(0 == strcmp(&path[2], pathCheck));
>
>asserts, but does not print out the values of path and pathCheck. It would
>be nice to know what they are. (Maybe I need a debugger!)
>
>Someone mentioned a richer assert recently. I'm now convinced.
>
>Ideas?
>
>
>
>  
>
I discussed a printf style assert.

assert(<condition>, ...);

ie

assert(0 == strcmp(&path[2], pathCheck), "path (%.s) was not equal to pathCheck (%.s)", &path[2], pathCheck);

Although stack tracing and debugging has it's advantages (can you stack trace a static_assert?).

>
> I discussed a printf style assert.
>
> assert(<condition>, ...);
>
> ie
>
> assert(0 == strcmp(&path[2], pathCheck), "path (%.s) was not equal to
pathCheck (%.s)", &path[2], pathCheck);
>
> Although stack tracing and debugging has it's advantages (can you stack
trace a static_assert?).
>
>

Having both is still better (and ideally it should be possible to disable them.

And printing a string would also0 be usefull for static assert...

Using a string expression, one can display exactly what he wants to know if the condition fails.

Philippe

Philippe Mori wrote:

>>I discussed a printf style assert.
>>
>>assert(<condition>, ...);
>>
>>ie
>>
>>assert(0 == strcmp(&path[2], pathCheck), "path (%.s) was not equal to
>>    
>>
>pathCheck (%.s)", &path[2], pathCheck);
>  
>
>>Although stack tracing and debugging has it's advantages (can you stack
>>    
>>
>trace a static_assert?).
>  
>
>>    
>>
>
>Having both is still better (and ideally it should be possible to disable
>them.
>
>And printing a string would also0 be usefull for static assert...
>
>Using a string expression, one can display exactly what he wants to know if
>the condition fails.
>
>Philippe
>
>
>  
>
Exactly my sentiments (except for the disable part, asserts and stack-traces are already disabled for release build). Particularly when tracing a static assert is non-sensical (as I hinted before).

-Anderson