On 04/25/2011 07:42 AM, Gennadiy Rozental wrote:
Yes. This is indeed the case. Boost.Test (for now at least) do not have any dependencies on threading libs. Meanwhile, you can write simple wrappers around Boost.Test testing tools you are using, which will lock some global lock and perform the action of the tool.
I tried to write a few wrappers, it isn't so trivial. The main issue is that we can't be locking a mutex /unless/ the test condition fails, otherwise it would significantly interfere with the test. So my wrappers first do the check and then call the normal boost tool. However, certain things like CHECK_CLOSE I couldn't figure out. I found the "is_close" static instance but couldn't get it working correctly. Is there perhaps a standard way that I can just do the tool test and have a bool result returned? That would make writing the wrappers a lot simpler, I could just make them look like this: #define THREAD_CHECK_CLOSE( a_, b_, p_ ) \ if( !BOOST_BOOL_CLOSE( (a_), (b_), (p_) ) ) \ BOOST_CHECK_CLOSE( (a_), (b_), (p_) ) With locking added inside the if statement. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail.