Boost logo

Boost :

Subject: Re: [boost] suggestion on assertion macros
From: Roland Bock (rbock_at_[hidden])
Date: 2010-03-14 09:48:48


Mateusz Loskot wrote:
> Emil Dotchevski wrote:
>
>> On Sat, Mar 13, 2010 at 2:43 AM, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
>>
>>> This is a good addition to assertions, but once we decide that we are
>>> improving assertions, there is much more that needs an improvement.
>>> Most of them are listed in the thread on Contract++ library (proposed
>>> for Boost) that you are already referring to. But let me list the
>>> potential improvements here.
>>>
>> Why don't we leave assertions alone? Anything you do to "improve" them
>> makes them more tolerable which makes them something other than
>> assertions.
>>
>> Assertions should print a message and exit.
>>
>
> Well said.
>
> The idea of "Be able to disable some assertions, " sounds
> especially weird. Assertions are not for purpose of logging
> and such. Categories of assertions severity make little
> sense to me.
>
> Best regards,
>

I couldn't agree more, but removing the compile time warning in cases
like the following does not change the nature of assertions.

void my_method(const int& my_param)
{
    assert(my_param);
}

Currently I get compiler warnings about my_param being unused when
compiling with NDEBUG defined. I'd be glad to get rid of them. And I
certainly do not want to have my code sprinkled with

#ifdef NDEBUG
void my_method(const int&)
#else
void my_method(const int& my_param)
#endif
{
    assert(my_param);
}

Regards,

Roland


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk