October 2013 - Boost - lists.preview.boost.org

[log] MSVC 9 build hangs
by Andrey Semashev 04 Oct '13

04 Oct '13

Hi, Many test results for Boost.Log on teeks99-03b-win2008-64on64 [1] show that the build aborts due to timeout. From the test setup description (2 GiB of RAM, 2 CPUs, 4 build jobs) it seems that the problem could be in the insufficient system resources. 4 jobs building Boost.Log can easily exceed 2 gigs of RAM, especially considering some of the memory is reserved by OS and other programs. If there isn't any swap, the build may be just aborting, and if there is, it's probably performing dead slow. And 2 cores might also be too limiting. Could the tester take a look what is happening on that setup? If it's not a resource problem, then I would appreciate any information on the problem. [1] http://www.boost.org/development/tests/trunk/developer/log.html

3 27

[ASIO] Safely shut down timer thread in boost::asio::io_service in Windows DLL
by Bo Peng 03 Oct '13

03 Oct '13

Hi folks, As you might already know, Windows DLL has quite some limitation about what you can do during its loading and unloading. For example, you can't 'join' a thread when unloading a DLL. The consequence of doing that, from my opinion, is quite serious: it will hang the process in a dead lock. I have a Windows DLL, which uses boost::asio::deadline_timer. I found that deadline_timer::async_wait creates a timer thread as a private member of io_service. This thread won't be shut down even if all the timers are cancelled. In the destructor of io_service, 'join' will be called on the thread. In some exceptional situation, users might exit their main function before destructs the io_service inside my DLL, so the destructor is called during the unloading of the DLL, which hangs their process. The following code demonstrates this issue. action.h and action.cpp are the code for the dll, main.cpp are the code for the application which uses the dll. action.h: #pragma once #ifndef _WIN32_WINNT #define _WIN32_WINNT 0x0501 #endif extern "C" __declspec(dllexport) void start(); extern "C" __declspec(dllexport) void stop(); action.cpp: #include "action.h" #include <boost/asio.hpp> #include <boost/bind.hpp> #include <boost/shared_ptr.hpp> #include <boost/thread.hpp> class Action { public: Action() : ios_(), timer_(ios_, boost::posix_time::seconds(1)), worker_() { } void start() { worker_.reset(new boost::thread(boost::bind(&Action::startEntry, this))); } void stop() { if (worker_) { ios_.post(boost::bind(&Action::stopEntry, this)); worker_->join(); worker_.reset(); } } private: void startEntry() { timer_.async_wait(boost::bind(&Action::timerHandler, this, _1)); ios_.run(); } void stopEntry() { timer_.cancel(); } void timerHandler(const boost::system::error_code& e) { if(e == boost::asio::error::operation_aborted) { std::cout << "Finished." << std::endl; } else { std::cout << "Triggered." << std::endl; timer_.expires_from_now(boost::posix_time::seconds(1)); timer_.async_wait(boost::bind(&Action::timerHandler, this, _1)); } } boost::asio::io_service ios_; boost::asio::deadline_timer timer_; boost::shared_ptr<boost::thread> worker_; }; boost::shared_ptr<Action> action; void start() { action.reset(new Action); action->start(); } void stop() { if (action) { action->stop(); action.reset(); } } main.cpp: #include <iostream> #include <windows.h> int main() { typedef void (__cdecl *PROC)(); HINSTANCE hInstLib = LoadLibrary(TEXT("dll.dll")); if (hInstLib == NULL) { std::cout << "Failed to load dll" << std::endl; return 1; } PROC startProc = reinterpret_cast<PROC>(GetProcAddress(hInstLib, "start")); if (startProc == NULL) { std::cout << "Failed to load start function" << std::endl; return 1; } PROC stopProc = reinterpret_cast<PROC>(GetProcAddress(hInstLib, "stop")); if (startProc == NULL) { std::cout << "Failed to load stop function" << std::endl; return 1; } startProc(); std::cout << "Press any key to exit..." << std::endl; getchar(); //stopProc(); FreeLibrary(hInstLib); return 0; } As you can see, stopProc() is commented out to simulate that the user doesn't have the chance to call the clean up function of my DLL. What I am wondering is, is it possible to shut down the thread whenever there isn't any timer outstanding. Or if I had access to the handle of this thread, I could call TerminateThread, which is allowed even during dll unloading. Regards, Bo

2 2

[graph] ranges used by boost.graph not compatible with c++11 range-based-for
by Nathan Ridge 03 Oct '13

03 Oct '13

>> Sadly, I don't think there s a way of turn an std::pair of iterators into >> a range-based-for-compliant range (see [1]). > > correct me if I'm missing something, but when performing ADL the > namespaces of the template parameters > are in the set of associated namespaces. So, one could simply overload > begin/end in the namespace where > the iterator types are defined ... You're right, a per-namespace solution is possible. I don't think it can be done in general, though (i.e. for all std::pairs of iterators in one stroke). I'm not familiar with BGL - are the iterator types in question defined in a namespace under the library's control, or could they be user-provided types (in which the case the user would have to put the begin()/end() in their own namespace)? Regards, Nate

2 1

[graph] ranges used by boost.graph not compatible with c++11 range-based-for
by Gabriel Redner 03 Oct '13

03 Oct '13

I noticed today that code of this form does not compile: typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Node, Edge> Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; typedef boost::graph_traits<Graph>::edge_descriptor Edge; Graph graph = ...; Vertex vertex = ...; for (Edge edge: boost::out_edges(vertex, graph)) {...} The reason is that out_edges returns a std::pair of iterators. This is a valid range in the sense of boost.range, and so is compatible with BOOST_FOREACH. However, this is not a valid range in the sense of c++11 range-based-for. It's not clear whether this can easily be changed. In a perfect world these functions should probably return something like boost::iterator_range which would be compatible with both boost- and language-level concepts of range-ness. However, the graph documentation explicitly names the return types of out_edges et. al. (see [1]) as std::pairs, which eliminates some wiggle room. Is there an alternate way to address this? -Gabe [1] http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/IncidenceGraph.html

4 4

Heads up: 1.55.0 deadlines approaching
by Marshall Clow 02 Oct '13

02 Oct '13

See the calendar at: http://www.boost.org/development/index.html September 16: 1.55.0 Closed for new libs and breaking changes September 23: 1.55.0 Closed, except bug fixes and doc changes September 30: 1.55.0 Closed, except by permission October 7: 1.55.0 Beta release -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

6 10

[accumulators] Help understanding implementation of weighted accumulators
by Gabriel Redner 02 Oct '13

02 Oct '13

Hi folks, I am trying to implement a weighted accumulator, but I'm having trouble understanding a few things about the existing ones. Looking at the implementation of weighted_sum, I see (weighted_sum.hpp:37): template<typename Args> weighted_sum_impl(Args const &args) : weighted_sum_( args[parameter::keyword<Tag>::get() | Sample()] * numeric::one<Weight>::value ) { } My questions are: - It's taking the first sample from the args and multiplying it by a weight of 1. Isn't this wrong - ignoring the real weight of this sample? Shouldn't this produce incorrect results? - I've never understood anyways how there can be an initial argument during construction of the accumulator. I haven't found any explanation in the docs beyond "Maybe there is an initial value in the argument pack". Maybe? How? Probably more questions later. Thanks, -Gabe

2 4

[thread] semaphore
by Tim Blechmann 02 Oct '13

02 Oct '13

hi all, i've submitted an implementation of semaphores for boost.thread to trac [1]. they provide an interface similar to boost.interprocess semaphores, with the exception of having chrono-style try_wait_for and try_wait_until members for timed_wait. the patch provides the following implementations: * win32 semaphores (tested with windows 8) * posix semaphores (tested with linux) * dispatch semaphores (tested with osx 10.8) * mutex/condition_variable/counter emulation the native implementations are much faster than the fallback, in microbenchmarks with high contention, i've seen a speedup of 30 to 80. would be great if they can be incorporated into boost.thread. comments/suggestions on the API are highly appreciated. cheers, tim [1] https://svn.boost.org/trac/boost/ticket/8797

10 29

Is there interest in a Simulation library?
by Damian Vicino 01 Oct '13

01 Oct '13

Dear All, Following the on-going efforts on development and standardization of C++, especially application-oriented libraries, we are soliciting expression of interest within the C++ community for a new Boost library for building Discrete-Event simulators. We plan to build this new library on the latest features of the C++11 standard, for possible inclusion in a future version of the C++ standard. This work is based on our experience in building C++-based simulators for over 20 years, exploring various optimization and algorithms, and leading to a significant number of reseach publications. Writing a new version of a simulation library based on the latest features of the C++ language has started as new joint research project of University of Nice Sophia Antipolis, UMR CNRS 7172 (FR), INRIA Sophia Antipolis (FR), and Carleton University (CAN). Of course, anyone interested in joined this effort is more than welcome! Damian Vicino, PhD Candidate Université Nice Sophia Antipolis & Carleton University Dr. Olivier Dalle, Maître de Conférences, Université Nice Sophia Antipolis Pr. Gabriel Wainer, Carleton University

5 13

[polygon] Release testing stalled... Missing source file.
by Rene Rivera 01 Oct '13

01 Oct '13

I commented out one of the test cases in the release branch because the source file for the test is non-existent. Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 1

testers blocked after changeset 85924 in trunk.
by Vicente J. Botet Escriba 01 Oct '13

01 Oct '13

Hi, the last change set that has been taken in account in trunk regression test is 85924. I'm expecting a lot of testers to cycle. Note that release regressing test are not blocked. Could someone explain what is happening? Best, Vicente

8 12