[assert][lightweight_test] Quick review of proposed changes
In reviewing the "[assert] static_assert envy" thread, I agreed with Steven Watanabe:
MHO, the last thing we need is lots of minor variations that don't add any real utility.
KISS was also a factor, as I wanted to add only features that I would personally use right away, or that were needed for BOOST_ASSERT compatibility. It boiled down to the following: [assert] * Added BOOST_ASSERT_MSG(expr, msg) macro. If expr is false, outputs msg, then calls std::abort(). BOOST_DISABLE_ASSERTS behaves the same as in BOOST_ASSERT. BOOST_ENABLE_ASSERT_MSG_HANDLER enables a separate error handler. BOOST_ASSERT_MSG_OSTREAM defaults to std::cerr. User may define to specify a different output stream. * Added BOOST_ASSERT_MSG test cases to libs/utility/assert_test.cpp * Added BOOST_ASSERT_MSG docs to libs/utility/assert_test.cpp <boost/detail/lightweight_test.hpp> has the same Visual Studio output interleaving problem, so it makes sense to apply a similar fix at the same time. * Messages are now sent do BOOST_LIGHTWEIGHT_TEST_OSTREAM * BOOST_LIGHTWEIGHT_TEST_OSTREAM defaults to std::cerr. User may define to specify the output stream for messages. Updated files: http://mysite.verizon.net/beman/assert.hpp http://mysite.verizon.net/beman/assert.html http://mysite.verizon.net/beman/assert_test.cpp http://mysite.verizon.net/beman/lightweight_test.hpp Let's do a quick review before these get committed to trunk. Say until Monday morning. (They won't go in 1.46.0; far too late for that.) Comments welcome! --Beman
Beman Dawes wrote:
BOOST_ENABLE_ASSERT_MSG_HANDLER enables a separate error handler.
I think that the existing BOOST_ENABLE_ASSERT_HANDLER should control the behavior of BOOST_ASSERT_MSG as well. It's very unlikely that users will want one of the macros to go to their own handler, and the other to keep calling std::abort, and in the current implementation, this is what will happen silently in existing projects that already define BOOST_ENABLE_ASSERT_HANDLER. I suspect that such users will prefer a link-time error, alerting them to the presence of BOOST_ASSERT_MSG macros in the program.
* Messages are now sent do BOOST_LIGHTWEIGHT_TEST_OSTREAM
I'm sorry if I missed the explanation for it... what is the use case of this feature?
http://mysite.verizon.net/beman/assert.html http://mysite.verizon.net/beman/assert_test.cpp http://mysite.verizon.net/beman/lightweight_test.hpp
You should add your name to the copyright.
On Sun, Jan 23, 2011 at 12:32 PM, Peter Dimov <pdimov@pdimov.com> wrote:
Beman Dawes wrote:
...
* Messages are now sent do BOOST_LIGHTWEIGHT_TEST_OSTREAM
I'm sorry if I missed the explanation for it... what is the use case of this feature?
The motivating use case is the Microsoft Visual Studio IDE, which treats cout and cerr as two separate streams. So you get all the cout output followed by all the cerr output, when what you really want is the equivalent of command line 2>&1 Just changing the lightweight_test.hpp output to std::cout isn't a good solution because (1) std::cerr is really the right stream for most uses, and (2) a change might break existing scripts that assume std::cerr. Detecting VC++ isn't a good solution because (1) there doesn't seem to be any way to distinguish between compiling under the IDE versus the command line, and (2) there may be other IDE or test frameworks that have the same problem. Thus the macro. I'll add this comment: // IDE's like Visual Studio perform better if output goes to std::cout or // some other stream, so allow user to configure output stream:
http://mysite.verizon.net/beman/assert.html http://mysite.verizon.net/beman/assert_test.cpp http://mysite.verizon.net/beman/lightweight_test.hpp
You should add your name to the copyright.
Will do. --Beman
Beman Dawes wrote: ...
* Messages are now sent do BOOST_LIGHTWEIGHT_TEST_OSTREAM
I'm sorry if I missed the explanation for it... what is the use case of this feature?
The motivating use case is the Microsoft Visual Studio IDE, which treats cout and cerr as two separate streams. So you get all the cout output followed by all the cerr output, when what you really want is the equivalent of command line 2>&1
Thanks. I saw that <iostream> is conditionally included only when the macro is left undefined, and I wondered whether it shouldn't be included in either case. It seems to me that it should; the motivating use would then be #ifdef BOOST_MSVC #define BOOST_LIGHTWEIGHT_TEST_OSTREAM std::cout #endif instead of the less intuitive #ifdef BOOST_MSVC #include <iostream> #define BOOST_LIGHTWEIGHT_TEST_OSTREAM std::cout #endif Yes, in principle, the latter is "more correct", but I think that in practice the former is preferable.
On Mon, Jan 24, 2011 at 9:54 AM, Peter Dimov <pdimov@pdimov.com> wrote:
Beman Dawes wrote: ...
* Messages are now sent do BOOST_LIGHTWEIGHT_TEST_OSTREAM
I'm sorry if I missed the explanation for it... what is the use case of
this feature?
The motivating use case is the Microsoft Visual Studio IDE, which treats cout and cerr as two separate streams. So you get all the cout output followed by all the cerr output, when what you really want is the equivalent of command line 2>&1
Thanks. I saw that <iostream> is conditionally included only when the macro is left undefined, and I wondered whether it shouldn't be included in either case. It seems to me that it should; the motivating use would then be
#ifdef BOOST_MSVC #define BOOST_LIGHTWEIGHT_TEST_OSTREAM std::cout #endif
instead of the less intuitive
#ifdef BOOST_MSVC #include <iostream> #define BOOST_LIGHTWEIGHT_TEST_OSTREAM std::cout #endif
Yes, in principle, the latter is "more correct", but I think that in practice the former is preferable.
OK, will change. --Beman
On Sun, Jan 23, 2011 at 12:32 PM, Peter Dimov <pdimov@pdimov.com> wrote:
Beman Dawes wrote:
BOOST_ENABLE_ASSERT_MSG_HANDLER enables a separate error handler.
I think that the existing BOOST_ENABLE_ASSERT_HANDLER should control the behavior of BOOST_ASSERT_MSG as well. It's very unlikely that users will want one of the macros to go to their own handler, and the other to keep calling std::abort, and in the current implementation, this is what will happen silently in existing projects that already define BOOST_ENABLE_ASSERT_HANDLER. I suspect that such users will prefer a link-time error, alerting them to the presence of BOOST_ASSERT_MSG macros in the program.
KISS, I guess. Will change, --Beman
participants (2)
-
Beman Dawes -
Peter Dimov