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

lots of warning with gcc-4.8.1 + boost-1.54.0
by Neal Becker 04 Oct '13

04 Oct '13

Lots of warnings like this: ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally defined but not used [-Wunused-local-typedefs] when building 1.54.0 with gcc-4.8.1 (fedora f19)

8 9

[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

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

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

REQ: Looking for access to a Haswell machine to test Boost memory transactions code
by Niall Douglas 30 Sep '13

30 Sep '13

Dear Boost Devs, Last night I may have implemented some Boost macro based support for simple memory transactions. Basically one does this: STLLockable lockable; ... BOOST_BEGIN_MEMORY_TRANSACTION(lockable) { // Transaction code } BOOST_END_MEMORY_TRANSACTION(lockable) This can turn into __transaction_relaxed, or Intel TSX falling back onto a spin lock. It's very simple, but it ought to work and with very significant performance improvements on TSX capable hardware. The problem is that I don't have access to an Intel Haswell CPU to test the code upon. I think its design is correct through introspection, but if a kind Boost dev could lend me access to their Haswell machine via SSH - or even just offer to debug some binaries for me, I would be very grateful. Thanks, Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

2 2

[release][interprocess] regression in Windows
by Joaquin M Lopez Munoz 30 Sep '13

30 Sep '13

As indicated by the regression testers, see for instance: http://tinyurl.com/qabv7dm This is affecting also Boost.Flyweight, which uses <boost/interprocess/detail/intermodule_singleton.hpp> for its intermodule_holder component. Thank you, Joaquín M López Muñoz Telefónica Digital

2 1

Boost and clang under Windows
by Edward Diener 30 Sep '13

30 Sep '13

First off I am not of course proposing any changes to the upcoming release build of Boost 1.55 for clang under Windows. It turns out that clang under Windows, possibly to support the ability to use Windows header file, becomes another compiler which defines _MSC_VER. I believe the Intel compiler also does this but there may be some others. However clang is a much more strictly conforming to the C++ standard compiler than VC++ and does not have VC++'s quirks. This presents a problem in Boost. The Boost header files have numerous places where testing the macro _MSC_VER produces slightly different behavior based on the fact that the code is being used by VC++ or a compiler with the same behavior as VC++. But clang does not have the same behavior as VC++ despite defining _MSC_VER. Can I go ahead and change some of these situations as necessary to get clang under Windows to work properly with Boost code ? The usual change will be to test not only _MSC_VER but also that __clang__ is not defined for keeping the current implementation which assumes a VC++ compatible compiler with VC++ behavior. I am willing to make those changes in 'trunk' and keep an eye out for any significant failures in unit tests for our current regression tests. I have already made a slight change to Boost PP config.hpp on 'trunk' so that clang for Windows will pass the preprocessor tests. I am willing to work on other changes but I do not want to go ahead and do so if the maintainers of other libraries see any reasons for me not making the changes on 'trunk'. Of course I will test any changes I make locally to make sure they do not affect any other _MSC_VER defined compilers as well as with VC++. But the changes themselves should be fairly simple, just adding a check that __clang__ is not defined as part of the VC++ type behavior. Obviously something like the many tests for _MSC_VER in order to specify #pragma once will not change but some other situations will to exclude clang from the _MSC_VER functionality.

9 20