Boost logo

Boost :

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2007-12-23 19:41:48

"Ilya Sokolov" <fal_delivery_at_[hidden]> wrote in message
> Sorry for breaking into discussion but I have a bunch of related
> questions.
> Gennadiy Rozental wrote:
>> "Jens Seidel" <jensseidel_at_[hidden]> wrote in message
> [snip]
>> Because BOOST_TEST_MAIN produces both function main and empty init
>> function.
>> It's assumed that test units are automatically registered.
> Why both? Also, why defining BOOST_TEST_DYN_LINK switches on

1. Because alternatively I would've required 90% of the users to define 2
pretty closely names macro: BOOST_TEST_MAIN to define init function (this is
what this macro always did, so I can't change the meaning) plus another one
BOOST_TEST_MAIN_FUNCTION that will actually produce the function main()

2. Unfortunately original test modult function signature is unacceptable for
DLL initialization. So i had to introduce new one.

> Suppose I need to perform some initialization call, e.g.
> boost::filesystem::initial_path(). Currently, with shared Boost.Test I
> am forced to not to define BOOST_TEST_MAIN and to copy/paste the main()
> function like this:
> int BOOST_TEST_CALL_DECL main(int argc, char* argv[])
> {
> return boost::unit_test::unit_test_main(&init_unit_test, argc, argv);
> }

No. I don't think this is the best approach. Much better (and shorter)
solution is

struct init {
    init() { boost::filesystem::initial_path(); }


> Now if I want to support using static Boost.Test, I am forced to define

I always find it confusing: why would you want to support both static and
shared libraries? Pick one more convinient for you and stick with it. It's
not like you need to test your test module with all variants of Boost.Test
framework. It's your own test, not the test for the UTF. All in all I find
an effort for simultanious support for both static and shared variant of the
UTF a bit misguided.


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