Re: [boost] Boost.Tests: Unit test defines own main() function, why?

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

"Ilya Sokolov" <fal_delivery_at_[hidden]> wrote in message 
news:fkg1cd$gdv$1_at_ger.gmane.org...
> 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
> BOOST_TEST_ALTERNATIVE_INIT_API?

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(); }
}

BOOST_GLOBAL_FIXTURE( init );

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

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.

Gennadiy