Hi Everybody, I see there are mixed opinions on use of __assume in BOOST_ASSERT. The chief concern is there are people using BOOST_ASSERT in "uncommon" (but still valid) ways, such as: - to show dialog box, but only in debug mode - using assert handler to throw during unit testing - possibly more These types of usage would be prohibited if we introduced __assume into BOOST_ASSERT, so basically this is a no-no from stability point of view (nobody wants his code broken). Btw. the second way can be dealt with with disabling __assume if assertion handler is defined. On the other hand some people (including me) consider __assume to be nice, helping optimization and suppressing annoying warnings. I see 3 options: 1. BOOST_ASSUME =============================================== Put __assume in BOOST_ASSUME and leave BOOST_ASSERT unmodified. Pros: - does not disturb existing code in any way Cons: - no existing code uses it, i.e. all existing libraries would have to be modified to take advantage of it; this will probably never happen so most of the code will not benefit - obscure: most of the people would be confused about it when seeing it for the first time 2. BOOST_ASSERT + define to enable assume (default: on) =============================================== Pros: - does enable assume on all the boost code, some user programs get somewhat smaller and faster without any intervention from the programmer Cons: - breaks user code which uses BOOST_ASSERT in "uncommon" way. Would require a change in docs that executing BOOST_ASSERT(false) is undefined behavior (i.e. different than std::assert) BOOST_ASSERT + define to enable assume (default: off) =============================================== Pros: - does enable assume on all the boost code, some user programs get smaller and faster with a simple -D"BOOST_ASSERT_USE_ASSUME" on command line. Cons: - only small number of users will know about that #define, so probably most of the code will not benefit. What do you think? Marcin
On 9/23/05, Marcin Kalicinski <kalita@poczta.onet.pl> wrote:
Hi Everybody,
[snip]
BOOST_ASSERT + define to enable assume (default: off)
I prefer this way. That way wont need more testing to assure that wont come up strange bugs in user-code, and at the same time it allows for people who are willing to test it a little more to have better performance. The first option seems to me that just nobody is going to use it all, and the second option may give people optimization bugs for who dont really care about that much performance. I think the most balanced option is the third. [snip]
What do you think?
Marcin
Nice structuring of the problem. best regards, -- 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."
On 9/23/05, Marcin Kalicinski <kalita@poczta.onet.pl> wrote:
Hi Everybody,
I see there are mixed opinions on use of __assume in BOOST_ASSERT. The chief concern is there are people using BOOST_ASSERT in "uncommon" (but still valid) ways, such as:
- to show dialog box, but only in debug mode - using assert handler to throw during unit testing - possibly more
These types of usage would be prohibited if we introduced __assume into BOOST_ASSERT, so basically this is a no-no from stability point of view (nobody wants his code broken). Btw. the second way can be dealt with with disabling __assume if assertion handler is defined.
On the other hand some people (including me) consider __assume to be nice, helping optimization and suppressing annoying warnings. I see 3 options:
1. BOOST_ASSUME ===============================================
Put __assume in BOOST_ASSUME and leave BOOST_ASSERT unmodified.
Pros: - does not disturb existing code in any way
Cons: - no existing code uses it, i.e. all existing libraries would have to be modified to take advantage of it; this will probably never happen so most of the code will not benefit - obscure: most of the people would be confused about it when seeing it for the first time
I prefer this way. I do not think it's a hard concept to understand and it would be fairly trivial for authors to change their BOOST_ASSERTs to use it where appropriate. Using a define to change BOOST_ASSERT limits you to either having it on or off through the whole file, but BOOST_ASSUME would let you pick and choose which is best for the situation.
2. BOOST_ASSERT + define to enable assume (default: on) ===============================================
Pros: - does enable assume on all the boost code, some user programs get somewhat smaller and faster without any intervention from the programmer
Cons: - breaks user code which uses BOOST_ASSERT in "uncommon" way. Would require a change in docs that executing BOOST_ASSERT(false) is undefined behavior (i.e. different than std::assert)
BOOST_ASSERT + define to enable assume (default: off) ===============================================
Pros: - does enable assume on all the boost code, some user programs get smaller and faster with a simple -D"BOOST_ASSERT_USE_ASSUME" on command line.
Cons: - only small number of users will know about that #define, so probably most of the code will not benefit.
What do you think?
Marcin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
participants (4)
-
Cory Nelson -
Darren Cook -
Felipe Magno de Almeida -
Marcin Kalicinski