Hi All, What is the next step so that we can move forward towards adding BOOST_ASSUME macro to assert.hpp header? There's been a small discussion and so far every participant agreed that it is a nice thing to have. This is a very small addition, just a few lines. Is there a regular review needed? Marcin
What is the next step so that we can move forward towards adding BOOST_ASSUME macro to assert.hpp header?
Why is this not just the release configuration of BOOST_ASSERT?
That was the original idea but it was noted that it may break existing code (see excerpt below). IMHO it would be better to have BOOST_ASSERT expand to __assume, but it's just my opinion. Alternatively, we can make BOOST_ASSERT expand by default to __assume and add a macro, e.g. BOOST_ASSERT_NO_ASSUME, which prevents the expansion (to be used by these extremely rare cases where __assume breaks anything). == excerpt from original discussion === It looks to me as though this risks changing the semantics of BOOST_ASSERT in a way which might break existing code. As I read the documentation, currently code like: if (!p) { BOOST_ASSERT( false ); return; } is supported and meaningful. If BOOST_DISABLE_ASSERTS is true, the macro does nothing and the return statement is executed when p is 0. If we change the macro to instead expand to __assume, then the compiler will probably omit both return and the check against zero. The documented behaviour of the code will change. == excerpt ends === regards, Marcin
Marcin Kalicinski <kalita <at> poczta.onet.pl> writes:
What is the next step so that we can move forward towards adding BOOST_ASSUME macro to assert.hpp header?
Why is this not just the release configuration of BOOST_ASSERT?
That was the original idea but it was noted that it may break existing code (see excerpt below).
As I read the documentation, currently code like:
if (!p) { BOOST_ASSERT( false ); return; }
is supported and meaningful. If BOOST_DISABLE_ASSERTS is true, the macro does nothing and the return statement is executed when p is 0. If we change the macro to instead expand to __assume, then the compiler will probably omit both return and the check against zero. The documented behaviour of the code will change.
I don't get it. If you put BOOST_ASSERT( false ) anywhere, then you effectively say "never exceute this code". Otherwise there is an error in the assertion itself. So I don't see how it can break anything. (The effect of removing an assertion must not be any in a correct program). -Thorsten
On 9/21/05, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
I don't get it. If you put BOOST_ASSERT( false ) anywhere, then you effectively say "never exceute this code". Otherwise there is an error in the assertion itself.
So I don't see how it can break anything.
(The effect of removing an assertion must not be any in a correct program).
This is a very academic argument, in real life code that should never happen does and breaking code which tried to be robust to that is a bad idea. Personally, though, I'd probably want a #define to use old behavior until I could validate __assume won't break it.
On 9/21/05, Thomas Matelich <matelich@gmail.com> wrote:
On 9/21/05, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
I don't get it. If you put BOOST_ASSERT( false ) anywhere, then you effectively say "never exceute this code". Otherwise there is an error in the assertion itself.
So I don't see how it can break anything.
(The effect of removing an assertion must not be any in a correct program).
This is a very academic argument, in real life code that should never happen does and breaking code which tried to be robust to that is a bad idea. Personally, though, I'd probably want a #define to use old behavior until I could validate __assume won't break it.
IMO, this is not a very academic argument. In an assertion the code can really never happen. If it can sometimes happen, then it shouldnt be an assertion, but should throw an exception. Although I agree with you that it should have a #define for the old behavior, or maybe it should only use __assume if it's #defined something, like Marcin proposed in his response to Thorsten. -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
participants (4)
-
Felipe Magno de Almeida -
Marcin Kalicinski -
Thomas Matelich -
Thorsten Ottosen