"Ilya Sokolov" <fal_delivery@mail.ru> wrote in message news:fkg1cd$gdv$1@ger.gmane.org...
Sorry for breaking into discussion but I have a bunch of related questions.
Gennadiy Rozental wrote:
"Jens Seidel" <jensseidel@users.sf.net> 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