Re: [boost] [Test] XX_MESSAGE and evaluation of arguments

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-04-16 11:59:30

"Thorsten Ottosen" <thorsten.ottosen_at_[hidden]> wrote in message 
news:461E1311.3020101_at_dezide.com...
> Gennadiy Rozental skrev:
>> "Thorsten Ottosen" <thorsten.ottosen_at_[hidden]> wrote in message
>> news:461CF01A.4010209_at_dezide.com...
>>> Hi Gennadiy,
>>>
>>> When I use macros such as
>>>
>>>         BOOST_CHECK_MESSAGE( !evidence,
>>>                              "update evidence = " <<
>>> withEvidenceUpdate << ", evidence = " << *evidence );
>>>
>>> it annoys me that the second argument is evaluated even when the test
>>> should pass.
>>>
>>> In the case above, evidence is an optional<int>. It would be cool if the
>>> construction of the error messsage could be delayed until it was
>>> actually needed, to make the above scenario valid.
>>>
>>> Do you think that is possible?
>>
>> The problem is that I might need the message even if test passes(to print
>> confirmation massages, if log level is set to "all").
>
> I see.
>
>> Why exactly does it bother you?
>
> Because my test crashes :-)

Did it crash within Boost.Test code?

>> You could always workaround it with your own macro:
>>
>> #define MY_CHECK_MSG( expr, MSG ) \
>> if( (expr) ) \
>> {} \
>> else \
>>     BOOST_CHECK_MSG( false, MSG ) \
>> /**/
>>
>
> I could do that, but I prefer the library to handle such situations.
>
> Is it not possible to generate the message only when it is needed. For
> example, I don't use log level "all".

I will significantly complicate Test Tools macros. We will have to have the 
code in every assertion location that checks for log levels (that's besides 
the fact the decision on log entry inclusion/exclusion is currently 
encapsulated within unit test log component and is not accessible outside). 
Also test tools vararg impl function expects some arguments to be passed. 
All in all I'd prefer at this point not to compromise test tools design and 
implementation without well based issue report that doesn't have a different 
workaround.

Gennadiy