Re: conditional property

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-12 12:43:04

Vladimir Prus <ghost_at_[hidden]> writes:

> Zbynek Winkler wrote:
>
>> > If you ignore the 'feature.action' stuff, all it does is adding
>> > <define>NDEBUG is <optimization> is set to "speed". The motivation is
>> > that I found it rather strange when I found that NDEBUG is not set. And
>> > <optimization>speed seems like a good way to turn on NDEBUG.
>> >
>> > What do you think?
>>
>> It was a bit unexpected. But when looking into the builtin.jam I've
>> found the following comment:
>>
>> # When <optimization>speed is specified, we need to add <define>NDEBUG
>> # It is done via 'active' features, because it should be done for
>> # all targets built with <optimization>speed. Since <define> is free, it is
>> # not propagated, we can't just add it to 'release'. And we cannot make
>> # <define> propagated, because (i) free features cannot be propagated and
>> # (ii) this is dangerous.
>>
>> I agree that it is a good idea to have NDEBUG defined for release
>> builds. I am just not sure this is the best way. Could we do compose
>> feature instead? We could then add it the 'release' and 'debug' and make
>> it propagated (it would expand to <define>NDEBUG for release and
>> <define>_DEBUG for debug). That way it would be more predictable. It
>> would identify the variant used for building.
>
> There are two questions. First is when to set NDEBUG -- for 
> <optimization>speed or for <variant>release. 

The latter, IMO. Some people like to keep assertions on even in
optimized code.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com