April 2009 - Boost-users - lists.boost.org

[test] boost::test equivalent of CppUnit's "protectors" ?
by Tim Day 14 May '09

14 May '09

I've used both CppUnit and boost::test for C++ unittesting. Generally I prefer boost::test, mainly because the auto-test macros minimise the effort to setup tests. But there's one thing I really miss from CppUnit: the ability to register your own custom "protectors", instances of which automatically wrap all the run tests. (Technically, you install a test "listener", and that can wrap each test run in a protector scope. Multiple listeners and nested protectors are possible). I've found these invaluable in the past for monitoring unittests for unexpected side effects (e.g checking code hasn't changed the floating-point unit state flags, or messed with other global state). I can't see any equivalent in the boost::test documentation, although BOOST_FIXTURE_TEST_CASE maybe comes closest. (However, whereas a CppUnit protector can return a bool to indicate pass/fail, it's less clear to me how a fixture destructor should indicate failure). Any suggestions for how to best achieve the same thing as CppUnit's protectors in boost::test (and without updating the body of each test) ? Thanks for any advice Tim

2 6

Boost Unit Tests on iPhone
by Manfred Schwind 13 May '09

13 May '09

Hi, I successfully built the boost libraries for the iPhone and for the iPhone Simulator. Now I have done some work on cross plattform C++ code and I am testing this code with Boost Unit Tests. It's running fine on Mac and Windows. It's also running fine on the iPhone Simulator. But unfortunately it's not working on the iPhone Device. It's not even getting into my test code, it just "hangs" somewhere before when collecting the test cases, if I can see this right in the debugger. I experienced that if I just have one BOOST_AUTO_TEST_CASE it also works fine on the iPhone Device. The test case executes, it succeeds and the app quits. But as soon as I have two or more BOOST_AUTO_TEST_CASEs, none of these test cases gets executed and the iPhone just hangs forever and loops around in some boost unit test initialization code using "spinlocks" and "yields" ... Is this a known issue? Anyone successfully using Boost Unit Tests on iPhone? Any ideas what I could try? Thanks, Mani -- http://mani.de - friendly software iVolume - listen to music freehand LittleSecrets - the encrypted notepad Sahara - sand in your pocket Watchdog - baffle the curious

3 5

BOOST_AUTO_UNIT_TEST
by Ross Boylan 13 May '09

13 May '09

In Boost 1.34, the version just released with Debian Lenny, the release notes for Boost.Test say BOOST_AUTO_UNIT_TEST renamed to BOOST_AUTO_TEST_CASE. Old name still provided but deprecated As far as I can tell, the old name is not provided. Presumably I can provide my own definition to work around this. I am trying to make my code compatible with various releases of Boost (including older ones that use the old name), so I can't just replace all old names with the new one. Ross

2 3

[uuid] status?
by Mikko Vainio 12 May '09

12 May '09

Hi all, Is there any results of the mini-review process of the UUID library? Will the library be a part of boost anytime in the near future (say 1.40.0)? Cheers, Mikko

4 3

Re: [Boost-users] [asio] sync receive_from with timeout
by Michael Dehmlow 09 May '09

09 May '09

Ha this is exactly the problem I ran into not two days ago I agree it would be nice if there was a timeout for the library: I used to following: //Oh throw a sleep in there: while(!timeout.elapsed()) { boost::system::error_code ec; boost::asio::socket_base::non_blocking_io command(true); socket.io_control(command); bytesRead = _socket->read_some(boost::asio::buffer(data, dataBufferSize), ec); if(error&&boost::asio::error::would_block!=error) { //there is some other error the client has disconnected; } else { //I must have got some data or theres no data yet check bytesRead for that } boost::this_thread::sleep( boost::posix_time::milliseconds(100)); } No extra threads necessary. Stephan Menzel-3 wrote: > > Is the subject Jehova enough for you? ;-) > > Great. > > Well, I haven't raised the subject so far but I'd certainly like to do so > now. For years now I am not only a user but also an admirer of boost asio. > Something that has always puzzled me however is, why a timeout > functionality which is something very common and essential for sync IO > just doesn't seem to be there. > > I think there are cases where syncronous IO is a better way to go and no > async approach is sensible. In my case this is a collection of static > functions that do UDP communication and therefore have to be sync because > I just want them to be able to return and throw exceptions and be able to > be called from anyone at any time. > > As always when I stumble across the asio/timeout problem I start googling > around. When people raise the topic here they are usually pointed to an > answer Chris Kohlhoff gave to someone asking that: > > http://lists.boost.org/Archives/boost/2007/04/120339.php > > ... which is good for tcp and works alright even though in my opinion it > leaves the question why it has to be so compilicated to do something so > basic. IMHO sync IO is all but pointless without a timeout. > > Anyway, I started to turn this into a UDP version and ended up with > something very similar: > > inline void set_result(boost::optional<boost::system::error_code>* a, > boost::system::error_code b) { > a->reset(b); > }; > > template <typename MutableBufferSequence> > void udp_read_with_timeout(boost::asio::ip::udp::socket& sock, int tmo, > boost::asio::ip::udp::endpoint &endpoint, const MutableBufferSequence& > buffers) { > > boost::optional<boost::system::error_code> timer_result; > boost::asio::deadline_timer timer(sock.io_service()); > timer.expires_from_now(boost::posix_time::seconds(tmo)); > timer.async_wait(boost::bind(set_result, &timer_result, _1)); > > boost::optional<boost::system::error_code> read_result; > sock.async_receive_from(buffers, endpoint, boost::bind(set_result, > &read_result, _1)); > > sock.io_service().reset(); > while (sock.io_service().run_one()) { > if (read_result) > timer.cancel(); > else if (timer_result) > sock.cancel(); > } > > if (*read_result) > throw boost::system::system_error(*read_result); > }; > > > So now I started to go ahead with that but I had to notice two things. > First, the performance impact is massive to a point that forces me to > reconsider. Second, when I use that in a multithreaded environment the > whole thing seems to block in some threads randomly. I have made test > program where I have multiple threads using that method, just sending an > UDP request to a server and waiting for an answer using this function. In > one thread everything is slow but continously running. In more than one > thread it blocks for up to 5 or 6 seconds every few (10-20) runs for no > visible reason. In my scenario all those threads share a socket protected > by a mutex so if one of them blocks all will be halted. > > So I come to think this is not a good way to handle the problem. Does > anyone have some thoughts on that? May this be a bug in asio (1.38) or > perhaps in my function? Or is there a better way to do sync UDP IO with a > timeout functionality? > > Cheers... > > Stephan > > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > -- View this message in context: http://www.nabble.com/-asio--sync-receive_from-with-timeout-tp22326399p2233… Sent from the Boost - Users mailing list archive at Nabble.com.

3 3

[test] Crash when running my unit tests
by Christian Henning 08 May '09

08 May '09

Hi there, when I try to run my tests the unit testing framework seems to crash for no apparent reason. The point it's crashing is in unit_test_suite.ipp[263]. It seems to crash before entering the first test. The c++ runtime at this points tries to delete the memory of a string which triggers the assertion. _ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)); Here is my scenario: Everything used to run just fine before I added a new file containing more tests. Meaning all of my tests are scattered around a couple of files ( 20 files ) which sum up to about 120 tests. I don't think that this usage is anything but exceptional. When I exclude the new test file the tests are running fine. When including the new test file it crashes. I'm running the boost trunk on a windows xp using MSVC 2005. Anyone any idea what I can do about this? My code is available here: http://gil-contributions.googlecode.com/svn/trunk/ The tests are here: http://gil-contributions.googlecode.com/svn/trunk/gil_2/libs/gil/io_new/tes… Any help is more than welcome. Thanks ahead, Christian

4 11

[BGL] citing the Boost Graph Library
by Alejandro Marcos Aragón 06 May '09

06 May '09

Can anyone point me how to cite the Boost Graph Library in a paper? Is there any information in the boost website? Thank you all, Alejandro Aragón

4 3

boost::mutex synchronization problem
by Zachary Turner 05 May '09

05 May '09

I've been trying to figure out if there's a simple way using condition variables and mutexes to design a function with the following properties (cliffs notes first, and then longer version in case it's not enough info): 1) there is a section of code in the function such that two threads cannot enter that section at the same time. 2) after leaving the section of code, the thread should wait for something to happen (signalled by another thread) 3) the waits in step 2 should be awoken in the order they occured. Basically there are many threads that may want to post requests to read/write from the network. So I have a bounded buffer implementation that holds "work items", which can be of read requests or write requests. writes return immediately, but reads block until the read is finished, which is determined by when the actual network thread processes the work item and signals something. read requests should be able to enter the queue regardless of whether another read request is already pending, but obviously the blocked threads should awake in the same order that items were inserted into the queue. I thought of making a condition variable for each read work item, and storing it in the work item that goes in the queue, so the network thread can notify that. But I feel like there should be a better way that doesn't require potentially arbitrary numbers of condition variables. Thanks

3 3

[Signals2] Error on building project RELEASE
by Daniele Barzotti 04 May '09

04 May '09

Hi, I'm writing a library that use the following: #include <boost/asio.hpp> #include <boost/asio/serial_port.hpp> #include <boost/thread.hpp> #include <boost/signals2/signal.hpp> #include <boost/scoped_ptr.hpp> #include <boost/enable_shared_from_this.hpp> I retrieved Signals2 from svn on 15/04/09. When I build it like STATIC DEBUG lib all works fine, but when I switch to STATIC RELEASE I got two errors... The preprocessor statements are: FOR RELEASE: WIN32;_LIB;_WINDOWS;EUROATLIB_EXPORTS;_WIN32_WINNT=0x0501 FOR DEBUG : WIN32;_DEBUG;_LIB;_WINDOWS;EUROATLIB_EXPORTS;_WIN32_WINNT=0x0501 What could be the problem? Tnx, Daniele. -------------------------------------------------------- ATDispatcher.cpp C:\Programmi\Microsoft Visual Studio 9.0\VC\include\xutility(419) : error C2664: 'boost::signals2::detail::stack_allocator<T,n_stack_elements>::stack_allocator(boost::signals2::detail::stack_storage<T,10> *)' : cannot convert parameter 1 from 'boost::signals2::detail::stack_allocator<T,n_stack_elements>' to 'boost::signals2::detail::stack_storage<T,n_stack_elements> *' with [ T=std::_Aux_cont, n_stack_elements=10 ] and [ T=boost::shared_ptr<void>, n_stack_elements=10 ] and [ T=std::_Aux_cont, n_stack_elements=10 ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called C:\Programmi\Microsoft Visual Studio 9.0\VC\include\xutility(417) : while compiling class template member function 'std::_Container_base_aux_alloc_real<_Alloc>::_Container_base_aux_alloc_real(_Alloc)' with [ _Alloc=boost::signals2::detail::stack_allocator<boost::shared_ptr<void>,10> ] C:\Programmi\Microsoft Visual Studio 9.0\VC\include\vector(421) : see reference to class template instantiation 'std::_Container_base_aux_alloc_real<_Alloc>' being compiled with [ _Alloc=boost::signals2::detail::stack_allocator<boost::shared_ptr<void>,10> ] C:\Programmi\Microsoft Visual Studio 9.0\VC\include\vector(439) : see reference to class template instantiation 'std::_Vector_val<_Ty,_Alloc>' being compiled with [ _Ty=boost::shared_ptr<void>, _Alloc=boost::signals2::detail::stack_allocator<boost::shared_ptr<void>,10> ] G:\lib\boost_signals2\boost/signals2/detail/stack_vector.hpp(28) : see reference to class template instantiation 'std::vector<_Ty,_Ax>' being compiled with [ _Ty=boost::shared_ptr<void>, _Ax=boost::signals2::detail::stack_allocator<boost::shared_ptr<void>,10> ] G:\lib\boost_signals2\boost/signals2/detail/slot_call_iterator.hpp(39) : see reference to class template instantiation 'boost::signals2::detail::stack_vector<T,NumStackElements>' being compiled with [ T=boost::shared_ptr<void>, NumStackElements=10 ] G:\lib\boost_signals2\boost/signals2/detail/slot_call_iterator.hpp(41) : see reference to class template instantiation 'boost::signals2::detail::slot_call_iterator_cache<ResultType,Function>' being compiled Serial.cpp C:\Programmi\Microsoft Visual Studio 9.0\VC\include\xutility(419) : error C2664: 'boost::signals2::detail::stack_allocator<T,n_stack_elements>::stack_allocator(boost::signals2::detail::stack_storage<T,10> *)' : cannot convert parameter 1 from 'boost::signals2::detail::stack_allocator<T,n_stack_elements>' to 'boost::signals2::detail::stack_storage<T,n_stack_elements> *' with [ T=std::_Aux_cont, n_stack_elements=10 ] and [ T=boost::shared_ptr<void>, n_stack_elements=10 ] and [ T=std::_Aux_cont, n_stack_elements=10 ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called C:\Programmi\Microsoft Visual Studio 9.0\VC\include\xutility(417) : while compiling class template member function 'std::_Container_base_aux_alloc_real<_Alloc>::_Container_base_aux_alloc_real(_Alloc)' with [ _Alloc=boost::signals2::detail::stack_allocator<boost::shared_ptr<void>,10> ] C:\Programmi\Microsoft Visual Studio 9.0\VC\include\vector(421) : see reference to class template instantiation 'std::_Container_base_aux_alloc_real<_Alloc>' being compiled with [ _Alloc=boost::signals2::detail::stack_allocator<boost::shared_ptr<void>,10> ] C:\Programmi\Microsoft Visual Studio 9.0\VC\include\vector(439) : see reference to class template instantiation 'std::_Vector_val<_Ty,_Alloc>' being compiled with [ _Ty=boost::shared_ptr<void>, _Alloc=boost::signals2::detail::stack_allocator<boost::shared_ptr<void>,10> ] G:\lib\boost_signals2\boost/signals2/detail/stack_vector.hpp(28) : see reference to class template instantiation 'std::vector<_Ty,_Ax>' being compiled with [ _Ty=boost::shared_ptr<void>, _Ax=boost::signals2::detail::stack_allocator<boost::shared_ptr<void>,10> ] G:\lib\boost_signals2\boost/signals2/detail/slot_call_iterator.hpp(39) : see reference to class template instantiation 'boost::signals2::detail::stack_vector<T,NumStackElements>' being compiled with [ T=boost::shared_ptr<void>, NumStackElements=10 ] G:\lib\boost_signals2\boost/signals2/detail/slot_call_iterator.hpp(41) : see reference to class template instantiation 'boost::signals2::detail::slot_call_iterator_cache<ResultType,Function>' being compiled LRRPTokenizer.cpp --------------------------------------------------------

3 4

[asio] async write handler is not called until the socket is not closed
by Roman Shmelev 02 May '09

02 May '09

Hi! I've got very strange problem - handler passed to async_write is not called in time. What I mean - it is called only when socket is closed - then handler is invoked many times. Sometimes it is so, sometimes everything is fine. The main thing is that traffic exists. I mean - async writes get completed. I call io_service.run() in proper time, etc. Another moment - the first two times the handler is invoked, but not more. As I guess, the problem is somewhere in my code. But I ask you to point to probable reasons of such behaviour that breaks asio rules..

2 7