Re: [boost] BOOST_ASSUME_review_needed?
In-Reply-To: <loom.20050921T155516-756@post.gmane.org> nesotto@cs.aau.dk (Thorsten Ottosen) wrote (abridged):
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.
Although that's a reasonable point of view, it is not supported by the current documentation, according to which executing BOOST_ASSERT(false) is well-defined and not an error. With some configurations it will invoke boost::assertion_failed(), which will pop up a message box offering to ignore, abort or break into the debugger. As I said in my previous post, I find the current behaviour quite useful. I sometimes use assert as a convenient way of saying, "issue a warning message, but only in debug builds." I actually work with MFC and use their ASSERT macro rather than BOOST_ASSERT. From a selfish point of view I don't care what boost does here because it won't hurt me. My concern is that other people may have used BOOST_ASSERT the same way I use MFC ASSERT. If you're confident no-one has, fine - but I don't see anything in the documentation which says my use is wrong. The documentation does say, "The macro is intended to be used in Boost libraries", which I suppose means we don't need to worry about breaking end-user code.
(The effect of removing an assertion must not be any in a correct program).
Having assert expand to __assume would not be the same as removing it. -- Dave Harris, Nottingham, UK.
Dave Harris <brangdon <at> cix.compulink.co.uk> writes:
In-Reply-To: <loom.20050921T155516-756 <at> post.gmane.org> nesotto <at> cs.aau.dk (Thorsten Ottosen) wrote (abridged):
(The effect of removing an assertion must not be any in a correct program).
Having assert expand to __assume would not be the same as removing it.
In the sense that an assertion should never fail, so should all the assumptions hereby implied also always hold. Of course, if you sprinkle assertions all around your code just to see if certain code-path executed, it's a different matter. -Thorsten
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.
Although that's a reasonable point of view, it is not supported by the current documentation, according to which executing BOOST_ASSERT(false) is well-defined and not an error. With some configurations it will invoke boost::assertion_failed(), which will pop up a message box offering to ignore, abort or break into the debugger.
As I said in my previous post, I find the current behaviour quite useful. I sometimes use assert as a convenient way of saying, "issue a warning message, but only in debug builds."
Same here. I'm using John Torjo's SMART_ASSERT and I have lines like: SMART_ASSERT(false)(a)(b)(c).msg("Surely we never reach here?"); I.e. if it does reach here I can see the values of a,b and c and can immediately see if it is a use case I never thought of, or a program bug. But instead of adding BOOST_ASSUME() I'd prefer the use of _assume() in BOOST_ASSERT be controlled by a define and off by default. It is a relatively minor optimization so could just be enabled by those who need the speed and know their code does not do ASSERT(false). Darren
Darren Cook wrote:
But instead of adding BOOST_ASSUME() I'd prefer the use of _assume() in BOOST_ASSERT be controlled by a define and off by default. It is a relatively minor optimization so could just be enabled by those who need the speed and know their code does not do ASSERT(false).
Excuse me for my jumping late into the thread, but what are the situations where one would want to use a BOOST_ASSERT with __assume instead of assert?
On 9/21/05, Peter Dimov <pdimov@mmltd.net> wrote:
Excuse me for my jumping late into the thread, but what are the situations where one would want to use a BOOST_ASSERT with __assume instead of assert?
__assume on MSVC passes hints to the compiler for optimization, it assumes the expression is always true. So that a function like this: int f(int x) { __assume(x == 0) return x; } is optimized by the compiler and just returns 0, without checking for x. It really seems an interesting opportunity for using already assertions for optimizations. The original thread is "BOOST_ASSERT and __assume on MSVC" -- 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."
Felipe Magno de Almeida wrote:
On 9/21/05, Peter Dimov <pdimov@mmltd.net> wrote:
Excuse me for my jumping late into the thread, but what are the situations where one would want to use a BOOST_ASSERT with __assume instead of assert?
__assume on MSVC passes hints to the compiler for optimization, it assumes the expression is always true.
Yes, I actually knew that, but thought that assert on MSVC already does __assume. But it doesn't. Maybe it did once and they switched it back when developers complained, :-) or maybe I was just misremembering things.
Dave Harris wrote:
As I said in my previous post, I find the current behaviour quite useful. I sometimes use assert as a convenient way of saying, "issue a warning message, but only in debug builds."
[snip]
used BOOST_ASSERT the same way I use MFC ASSERT. If you're confident no-one has, fine - but I don't see anything in the documentation which says my use is wrong.
That would be me... I use the assert handler functionality to throw an exception during unit testing because the Test library can't deal with assert() very well, but throwing is OK and can be handled and reported far nicer.
The documentation does say, "The macro is intended to be used in Boost libraries", which I suppose means we don't need to worry about breaking end-user code.
FWIW, If it did break my code I'd just retain an old version and use that if I couldn't deal with the new behaviour another way. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
Kevin Wheatley wrote:
Dave Harris wrote:
As I said in my previous post, I find the current behaviour quite useful. I sometimes use assert as a convenient way of saying, "issue a warning message, but only in debug builds."
[snip]
used BOOST_ASSERT the same way I use MFC ASSERT. If you're confident no-one has, fine - but I don't see anything in the documentation which says my use is wrong.
That would be me... I use the assert handler functionality to throw an exception during unit testing because the Test library can't deal with assert() very well, but throwing is OK and can be handled and reported far nicer.
You need to be very careful here. If you have asserts in a destructor, they could throw and terminate your tests without any diagnostics! ATL has asserts in several destructors. Ideally, you would want the asserts to become test cases, i.e. CPPUNIT_ASSERT or BOOST_ASSERT but unfortunately, CPPUNIT_ASSERT throws an exception :(. - Reece
Reece Dunn wrote:
You need to be very careful here. If you have asserts in a destructor, they could throw and terminate your tests without any diagnostics! ATL has asserts in several destructors.
Ideally, you would want the asserts to become test cases, i.e. CPPUNIT_ASSERT or BOOST_ASSERT but unfortunately, CPPUNIT_ASSERT throws an exception :(.
Indeed, but doing that sort of thing in a destructor is real bad anyway, so just ensure the class is always in a good state preserving the invariants as much as poossible and not bother testing destructors directly but observe their effects using suitable mock style objects. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
participants (7)
-
brangdon＠cix.compulink.co.uk -
Darren Cook -
Felipe Magno de Almeida -
Kevin Wheatley -
Peter Dimov -
Reece Dunn -
Thorsten Ottosen