Boost logo

Boost :

Subject: Re: [boost] Call for Review: Boost.Test documentation rewrite
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2014-01-22 05:25:32

Rob Stewart <robertstewart_at_[hidden]> writes:

> On Jan 20, 2014, at 2:48 PM, legalize+jeeves_at_[hidden] (Richard) wrote:
>> Why can't we simply make things better immediately and then look at
>> anything that is new?
> It's fair to say that many are inclined in your favor. Gennadiy has
> said your docs don't document the new state of the library, so yours
> will be short lived if the new state is adopted fairly soon. OTOH, if
> the new APIs are rejected, releasing the new version will be delayed
> or never occur making your version long(er) lived. Given the idea of
> linking to your version as documentation of the deprecated APIs when
> (if) the new version is released, your docs will be useful for some
> time either way, and that bolsters your case. Still, the question
> remains whether you're willing to document the new APIs, too.

Somewhere along the way, I think the difference between the current and
new APIs has been exaggerated. As for as I'm aware, the only change is
to the assertion macros, which move to a more natural syntax:

BOOST_CHECK_EQUAL(a, b) becomes BOOST_TEST(a == b)
BOOST_CHECK_LT(a, b) becomes BOOST_TEST(a < b)
... etc.
... etc.
BOOST_WARN_EQUAL(a, b) becomes BOOST_TEST_WARN(a == b)

Other than adding documentation for BOOST_TEST, BOOST_TEST_REQUIRE and
BOOST_TEST_WARN, and trivial changes to tutorials to favour those
macros, everything Richard has written would remain the same.


Swish - Easy SFTP for Windows Explorer (

Boost list run by bdawes at, gregod at, cpdaniel at, john at