July 2014 - Boost - lists.boost.org

Request for feedback on design of concurrent_unordered_map, plus notes on use of memory transactions
by Niall Douglas 31 Jul '14

31 Jul '14

Dear Boost, Finally I have found some time to write up my experimentations with using transactional GCC or Intel TSX TM to make an improved concurrent_unordered_map. The quick tl;dr summary is this: 1. Transactional GCC is great iff you are happy accepting up to a 50% performance reduction in normal code execution. For a greenfield multithreaded project this is absolutely worth it due to the enormous savings in debug effort. 2. First generation Intel TSX isn't worth using in almost any common use case. The only common use place it makes sense is for almost always read only data which is *always* highly contended where speedups can approach linear to execution cores, and even then the refactoring you need to make to avoid writes to any cache line touched by any other thread will make your code slower than throwing everything inside a standard spin lock. Spin locks are well optimised and allow simple implementations, plus spin locks are very fast for uncontended use. Any Intel TSX (HLE, RTM) introduces penalties to uncontended use and seems to force a pipeline stall which can reduce single threaded performance by as much as 40%. 3. Trying to implement atomics-based logic to have the CPU select non-TSX during uncontended and TSX during contended comes out at best as slightly slower than always using TSX. This, for me, simply kills TSX v1.0, I no longer consider it worth thinking about till v2.0 is made by Intel. For reference for those wishing to repeat my experimentations, you can see the history of my four attempts at a concurrent_unordered_map at https://github.com/ned14/boost.spinlock/commits/concurrent_unordered_m ap2 plus benchmark results at https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Memory% 20Transactions%20Test%20Linux%20GCC%204.8/. So, onto my proposed new concurrent_unordered_map design, which is NOT a split ordered list design as Intel TBB or Microsoft PPL does it. I had four criteria for my concurrent_unordered_map design which were based on my needs for proposed Boost.AFIO: 1. erase() is safe. This is for me the big showstopper with split ordered list designs, and I think it probably is for most people. 2. insert(), find(), and erase() all had to have single threaded performance similar to a std::unordered_map<> with a spin lock around it i.e. fast. 3. Everything apart from rehashing should be able to be concurrent. This includes iteration, inserting, finding, erasing, sizing. 4. Memory transaction friendly. This means transactional GCC right now, but maybe some future Intel TSX v2.0 support later. This criterion, incidentally, *requires* C++ 11 noexcept support, or at least I can't see a way to avoid it otherwise (just to be clear, I am claiming that for the implementation to _efficiently_ use memory transactions it needs noexcept move construction for both key and mapped type). Designs tried and benchmarked and rejected: 1. Items in a bucket were kept via an atomic forward pointer to the next item and one used cmpxchg to insert and remove items. This had really great, even superb, performance for load factors near one, but became pathological for badly distributed hash functions (I'm looking at you libstdc++). Once you rehashed the hash function to make it better distributed, performance nose dived. I was tempted to override std::hash with a decent implementation ... 2. Items in a bucket were kept as as a linear list of hashes and atomic pointers to value_type's. Each atomic pointer's bottom bit was its spin lock to keep each item footprint small, so you could lock each individual item during usage. The problem here really was that how do you safely resize the table without a per-bucket lock, and that halved performance over a spinlocked unordered_map as transactions really didn't deliver as expected here. 3. I created a specialisation only for mapped types of some std::shared_ptr<> which let me implement a completely lock free design. Unfortunately it was also rather slow, also about half the performance of a spinlocked unordered_map. Atomic increments and decrements of the same cache line across execution cores are slow :) Final proposed design (comments welcome): * item_type is allocated via a rebind of the supplied allocator, and looks like: struct item_type { value_type p; size_t hash; }; If value_type has a big sizeof(), a very good idea is to make the above a unique_ptr as otherwise you can't pack many item_type's into a cache line (AFIO's value_type is a std::pair<size_t, std::shared_ptr<>> which is 24 bytes, so item_type is 32 bytes which works well for my purposes). * bucket_type looks like this: struct bucket_type { spinlock<bool> lock; atomic<unsigned> count; // count is used items in there std::vector<item_type, item_type_allocator_type> items; char pad[64-sizeof(spinlock<bool>)-sizeof(atomic<unsigned>)-sizeof(std::vec tor<item_type, item_type_allocator_type>)]; }; static_assert(sizeof(bucket_type)==64, "bucket_type is not 64 bytes long!"); Note that items has its capacity directly managed, and is always expanded to powers of two. The size of actual items stored can float between zero and capacity. * And finally, concurrent_unordered_map itself merely contains: template<class Key, class T, class Hash=std::hash<Key>, class Pred=std::equal_to<Key>, class Alloc=std::allocator<std::pair<const Key, T>>> class concurrent_unordered_map { spinlock<bool> _rehash_lock; hasher _hasher; key_equal _key_equal; std::vector<bucket_type> _buckets; }; * To insert or find an item involves determining the bucket from the modulus of the hash by the number of buckets, locking the bucket and scanning the linear list for an empty item or the right item as appropriate. We know empty items from a magic hash value which is defined to some magic constant (advice on the best magic hash value least likely to turn up from std::hash is welcome). find() starts from the start of the list forwards, insert() starts from the end of the list backwards to help with cache line contention. As insert() needs to check for key matches as well as for empty slots, it needs to happen anyway, but if we knew key collision could never happen we could detect when the table is full from the atomic count and skip the table scan. If insert doesn't find a match nor an empty slot, if there is capacity it appends the item, if no capacity a capacity doubling is done and then an append. If capacity doubling occurs, all references to items in that bucket become invalid. I intend an insert_stable() API which will refuse to modify capacity, plus a bucket_reserve() API. insert() and find() have O(avrg bucket size (not count)). On transactional GCC find() and the initial seach for key equivalence in insert() are implemented as transactions without locking the bucket. All modifications are done by locking the bucket. This was found to have the best performance through trial and error. * To erase an item is easy: iterators store an iterator to the bucket and an offset into the linear table. Erasure involves constructing a temporary value_type, locking the bucket and performing a *move* construction out of the table into the temporary value_type, resetting the hash to empty. Destruction can then occur without holding the bucket lock. If the item just erased is the last in the bucket, the bucket's size (not capacity) is reduced by one, and that is repeated until the bucket size is the minimal possible. I currently violate STL allocator requirements here because I don't use the allocator for the temporary value_type to avoid a usually pointless malloc. Any suggestions on how to fix this would be welcome. You'll note that erasure here is safe as its storage never moves, though if you concurrently use and erase the same item you'll get a race onto a destroyed item which is as expected. erase() is O(1). * size() under this design becomes O(bucket count) as we sum the count members of each bucket. empty() is worst case O(bucket count) when the map is empty, best case O(1) when the first bucket is not empty, average case O(bucket count/item count/2). * Iteration under this design is queerly inversely dependent on load factor - with the higher the load factor, the better the performance. This is because we don't bother with the usual forward pointer per item as those are expensive for concurrent use and doubly linked pointers are rather a lot of overhead per item, so iteration is a case of iterating linear tables and once completed, searching for the next non-empty bucket which in a sparsely occupied bucket list is very lumpy as cache lines are pulled one by one into the cache. * rehash() under this design firstly locks the special rehash lock, then locks every bucket in the list. It then constructs a new empty bucket list and locks every lock in that. It then swaps the bucket lists, and moves all the items from the old buckets to the new buckets. It finally unlocks all the buckets, and the special rehash lock. This function is hard to write completely race free under all CPU load circumstances without burdening the main API implementations. I may use the concept of keeping around the old just emptied bucket list which is permanently marked to users as "go reload the bucket list" to work around this, and then document that you must not rehash too frequently or else you will race your code. Note that rehashing under this design is completely manual. If it were not, insertion, erasure and item referencing could not be safe. This implies that if you rehash, it is up to you to not be using items by reference at the time. Rehashing is also by definition not concurrent, indeed it is the only function in the design which is not capable of concurrency. Thoughts on this design before I write a final implementation are welcome. I don't plan to complete my implementation past the minimum needed for proposed Boost.AFIO, so if someone else wishes to finish it that and make it part of official Boost that would be great. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 6

Fwd: [sync?] "Distributed" value (or something...)
by Klaim - Joël Lamotte 31 Jul '14

31 Jul '14

---------- Forwarded message ---------- From: Klaim - Joël Lamotte <mjklaim(a)gmail.com> Date: Tue, Jul 29, 2014 at 9:44 PM Subject: [boost][sync?] "Distributed" value (or something...) To: Boost users list <boost-users(a)lists.boost.org> I would like to ask Boost developers and users: 1. Am I the only one seeing the following pattern in my concurrent systems code? 2. Is there already some tools available in Boost that does what I describe here and that I am not aware of? 3. If not, would there be any interest in the tool I'm describing here or not? Is it a dumb idea? (I keep getting back to this idea but I'm surprised not finding anything similar online) The pattern that I am seeing occurs when: 1. I have a value or a set of values in an object or several objects which value(s) describe some kind of configuration that several other systems will read and use. 2. The object(s) will be updated only by one thread (at a time). 3. When the object's value is modified, all the systems that rely on the object's value have to be notified so that they update themselves using that value. 4. The systems I am refering to can use different threads for updating and we can assume that they are running concurrently. 5. It is not important that the source object's value is synched with the reader's values at all time, however it is important that the sequence of changes to the source object's value is signaled to the readers exactly in the same order and "as fast as possible", but delay is ok. The simplest solution to solve this is to have a mutex locking the value and the systems checking the value regularly. (that is, using syncrhonized_value for example) However the locking and looping reads might not be necessary if it is done in another way (if I am correct, I still lack experience in the domain). The solution that I am thinking about would look like this. ///////// // The object containing the value used by the other systems. class System_A { distributed_source<int> m_foo_count; // changes to this object will be sent to "readers"... public: System_A() : m_foo_count(42) ... {} //... // thread-safe read-only access distributed_value<int> make_foo_count_reader() const { return distributed_value<int>{ m_foo_count }; } }; ///////// // The different systems acquire a read access to the value. class System_B { distributed_value<int> foo_count; // read-only value reflecting System_A::m_foo_count's value since last update. public: SystemB( const System_A& system_a, ... ) : m_foo_count( system_a.make_foo_count_reader() ) { // setup the initial config... on_foo_count_changed( *m_foo_count ); // trigger some processing when SystemA::foo_count's value have been changed: m_foo_count.on_changed( [this]( int new_value ){ // called after the value have been changed m_work_queue.push( [=]{ // will be executed on the next update cycle for this system... on_foo_count_changed( new_value ); / }); }); } //... private: void update_cycle( const UpdateInfo& info ) { // ... // the following is just to clarify: const int foo_before = *m_foo_count; // the value is not updated yet, but we can still use it m_work_queue.execute(); const int foo_after = *m_foo_count; // the value might have been udpated if( foo_before != foo_after ) { // the value have been updated (though you don't need to do this if you used the callback instead). } //... }; }; //////// // At some point the value is changed by the system owning the source object... System_A::change_foo( int new_value ) { m_work_queue.push( [=]{ // will be executed on the next update cycle of this system... // ... *m_foo_count = new_value; // assign the new value then send the new value to the readers... }); } System_A::something_complex( std::function<void(int&)> some_work ) { m_work_queue.push( [=]{ // ... m_foo_count.update( some_work ); // execute on the current value then send the resulting value to the readers }); } Some notes: a. The names are just invented while I write this email. b. I suppose that the distributed_source might have an interface similar to synchronized_value, anyway I didn't get farther than this idea. c. I see several different ways to implement this idea, some might be more efficient than others but I didn't do any tests yet (by lack of time). Thoughts?

3 7

Documentation appears to have part of boost::mpi::packed_iarchive and boost::mpi::packed_oarchive reversed?
by Dominic Marcello 31 Jul '14

31 Jul '14

Hello It seems like the documentation for boost::mpi::packed_iarchive and boost::mpi::packed_oarchive are reversed. boost::mpi_packed_iarchive uses MPI_Unpack and boost::mpi::packed_oarchive uses MPI_Pack. This can be verified by looking at the packed_iprimitive and packed_oprimitive base classes. The documentation, as well as the packed_iarchive and packed_oarchive header files, however, say the opposite - that packed_oarchive uses MPI_Unpack and packed_iarchive uses MPI_Pack. -Dominic

2 1

Clang on Windows
by Matthew Musto 31 Jul '14

31 Jul '14

I attempted to run Clang 3.4.1 on Win 8.1 with horrible results as evident on the current master regression summary here: http://www.boost.org/development/tests/master/developer/summary.html Besides the fact that boost identifies it as linux clang and there appears to be numerous other issues with the b2 script, has anyone had any success with this? The reason I ask is AMD is using LLVM for their heterogeneous development and I'm trying to see if boost will be something I can count on. Thanks, -Matt

1 0

b2 headers is unreliable on 1.56 on Windows
by Niall Douglas 30 Jul '14

30 Jul '14

Anyone else found that b2 headers in 1.56 randomly misses things to hard link on Windows? If you run it four or five times it eventually hard links everything through monte-carlo, but it is a bit annoying. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

Lock free condition_variable or using shared_lock
by Kirk Liberty 30 Jul '14

30 Jul '14

I'm not too familiar with the mechanisms which underlie mutexs and conditionals, which is why I'm asking this question. Is it possible to modify condition_variable so that wait() can be called on shared_lock? The use case would be it is acceptable to release all threads waiting on a condition_variable when notify_all() is called. Using a unique_lock, every thread who wakes up will then have to obtain the lock before proceeding; this being a potential bottleneck. An even more performant alternative to using shared_lock would be with a dummy lock never blocks when dummy_lock.lock() is called. These are things I would like to contribute, but I need would need some guidance and a review of feasibility. Thanks for the help, Kirk

3 2

News about proposed Boost.Application library
by Renato Forti 30 Jul '14

30 Jul '14

Hi All, This e-mail is only to inform news about proposed Boost.Application library. We have done many updates on version 0.4.9, see: - MinGW support; - The ‘auto_handler’ class to bind ‘stop’, ‘pause’, ‘continue’ and ‘single instance’ handlers automatically; - New samples for ‘auto_handler’; - Many fix and improvements on ‘Windows Server’ (Service API) mode; - Simplification of ‘handlers’ creation, now application context can by passed on constructor of functor, or user can use global version of it; - Docs are updated to version 0.4.9; - And many others small fixes. To know more, please visit: https://github.com/retf/Boost.Application Article (0.4.8) http://www.codeproject.com/Articles/756866/Build-a-Server-Application-using… (Prize winner in Competition "Best C++ Article of April 2014" ) Thanks

7 20

[trac] Adding new components (Align, Type_Index)
by Michel Morin 30 Jul '14

30 Jul '14

Wouldn't it be better to add newly introduced libraries Align: glenfe (Glen Fernandes) Type_Index: apolukhin (Antony Polukhin) to trac components? Regards, Michel

1 0

[quickbook] disambiguate overloaded function
by Benedek Thaler 30 Jul '14

30 Jul '14

Hi, I'm using quickbook and doxygen to generate my documentation. Suppose I have the following functions: func(int); func(std::string); They have separate reference pages, I'd like to link to them. However, I can't specify which one I mean using quickbooks funcref construct: [funcref func text] // results in: Reference to function 'func' is ambiguous. How can I specify the overload? Thanks, Benedek

1 0

Re: [boost] [geometry] Querying for Points nearest to a Segment.
by Adam Wulkiewicz 30 Jul '14

30 Jul '14

2014-07-29 3:07 GMT+02:00 Jeremy Murphy <jeremy.william.murphy(a)gmail.com>: > Veering slightly off topic but still related to Geometry development, I've > hit some hurdles with the rtree index. I could create an index of points > easily but then couldn't query for the nearest neighbour of a segment. (I > assume this is simply not supported at present; is it forthcoming?) So I > created a ring or polygon from the segment and tried to query for the > points that it covers/intersects, which is a feature listed in the > documentation, but I've hit this compilation error: > > > /usr/include/boost/geometry/algorithms/detail/overlay/get_turn_info.hpp:932:32: > error: no matching function for call to > ‘boost::geometry::model::referring_segment<const > boost::geometry::model::d2::point_xy<double> >::referring_segment(const > boost::geometry::model::point<double, 2ul, > boost::geometry::cs::cartesian>&, const > boost::geometry::model::point<double, 2ul, > boost::geometry::cs::cartesian>&)’ > > This constructor for referring_segment looks OK to me, except maybe for the > 'const' qualifier on the arguments? > Which version of Boost are you using? Indeed nearest(segment, ...) shouldn't work in 1.55. However intersects(ring_or_poly) should. Could you prepare some minimal failing example? E.g. this compiles for me, using develop branch (upcomming 1.56) or 1.55 without one, marked line: #include <boost/geometry.hpp> #include <boost/geometry/index/rtree.hpp> #include <boost/geometry/geometries/segment.hpp> #include <boost/geometry/geometries/ring.hpp> namespace bg = boost::geometry; namespace bgi = bg::index; typedef bg::model::point<double, 2, bg::cs::cartesian> P; typedef bg::model::segment<P> Seg; typedef bg::model::ring<P> Ring; typedef bg::model::polygon<P> Poly; typedef P V; int main() { typedef bgi::rtree<V, bgi::linear<16, 4> > RT; //typedef bgi::rtree<V, bgi::quadratic<16, 4> > RT; //typedef bgi::rtree<V, bgi::rstar<16, 4> > RT; RT rt; V v; rt.query(bgi::nearest(Seg(), 1), &v); // Using 1.55 without this line rt.query(bgi::intersects(Ring()), &v); rt.query(bgi::intersects(Poly()), &v); } Regards, Adam

3 3

[1.56.0 b1] Issue with mpl/is_convertable/asio
by Thomas Suckow 30 Jul '14

30 Jul '14

In testing '1.56.0 Beta 1' I have found that I am unable to compile https://github.com/splunk/pion on RHEL6_x64 Pion compiles fine with 1.55.0 I suspect the recurring "anonymous enum" is the kicker, though I am not sure where to even begin in diagnosing this. error: ‘const boost::asio::detail::buffer_sequence_adapter_base::<anonymous enum>&’ is/uses anonymous type error: no type named ‘type’ in ‘struct boost::is_convertible<const boost::asio::detail::buffer_sequence_adapter_base::<anonymous enum>&, const boost::iterator_range_detail::iterator_range_tag&>’ error: ‘value’ is not a member of ‘boost::mpl::aux::nested_type_wknd<boost::is_convertible<const boost::asio::detail::buffer_sequence_adapter_base::<anonymous enum>&, const boost::iterator_range_detail::iterator_range_tag&> >’ Full error log: http://pastebin.com/yeScQCpx If I get a chance I will see if I can reproduce this on a more modern compiler. Any assistance in correcting this before the 1.56.0 release would be appreciated. It also may or may not be related to http://thread.gmane.org/gmane.comp.lib.boost.devel/253259/focus=253261 Regards, Thomas

3 4

quince: queries in C++ expressions
by Michael Shepanski 29 Jul '14

29 Jul '14

Hello, boost! I've released a library called "quince", which lets you use a relational database in C++ rather than SQL. So it provides an EDSL to wrap the SQL syntax, it converts between C++ types (including user-defined class types) and SQL column types, and it enforces type safety at compile-time. I wanted to ask whether there would be an interest in this for boost, so I subscribed to this list today, and for the first time I discover Roland Bock's sqlpp11, which does all of those things too. First of all I'd like to say: nice work Roland! The truth is, if I had seen sqlcpp11 earlier, I would not have had felt the need to write quince. Nevertheless, I did write it, and so of course it has a different set of features. The full doco is at http://quince-lib.com, but let me quickly point out a few differences from sqlpp11. 1. If you want some class to be mapped into SQL data, quince lets you write this sort of thing: struct point { float x; float y; }; QUINCE_MAP_CLASS(point, (x)(y)) extern database db; table<point> points(db, "points"); The macro QUINCE_MAP_CLASS uses a bit of Boost.Preprocessor magic and a bit of template metaprogramming to produce all the statically typed metadata that quince needs, regarding the user's type. There is no code generation step. 2. Quince's EDSL looks somewhat different. This is my first day as a student of sqlpp11, so I'm not really qualified to define the distinctions, but I think part of it is that sqlpp11 exposes the concept of column aliases, where quince does not, and quince is preoccupied with the idea of compositionality, in a way that sqlpp11 is not (as far as I know). Anyway you can see an example of the quince EDSL here: http://quince-lib.com/getting_started.html . 3. Just as sqlpp11 uses /connectors/, quince uses /backend libraries/, or /backends/. Currently I provide backends for PostgreSQL and sqlite. Unlike sqlpp11, however, I have not yet published the interface between quince and the backends. It's no secret --the whole lot is open source-- but I'm not yet ready to declare that I know all the customization points I'm going to need. 4. Quince provides mappings for std::tuple<T, ...> and boost::optional<T>, whenever it provides mappings for the Ts. E.g. a boost::optional<int32_t> is mapped as an INTEGER column with its NOT NULL constraint turned off. If you have a query q1 that produces results of type T1, and a query q2 that produces results of type T2, then q1.left_join(q2, some_predicate) produces results of type std::tuple<T1, boost::optional<T2>>. 5. An application can customize the representation of data in a particular database, or a particular table. 6. Quince does not currently provide bulk insert. (It's on my to-do list.) I've barely scratched the surface, but right now I have the impression that both products have their distinctive pluses. Keen to know your thoughts. Regards, --- Michael

10 48

name of boost 1.56 tarball
by Menelaos Karavelas 29 Jul '14

29 Jul '14

Hello. Unlike previous versions which are named with underscores only, the boost 1.56 b1 tarball is named boost-1_56_0_b1.{zip, tar.gz, tar.bz, 7z}. Unpacking the tarball creates a boost-1_56_0_b1 directory instead of the expected one boost_1_56_0_b1 See also: http://sourceforge.net/projects/boost/files/boost/1.56.0.beta.1/ http://sourceforge.net/projects/boost/files/boost/1.55.0/ http://sourceforge.net/projects/boost/files/boost/1.54.0/ http://sourceforge.net/projects/boost/files/boost/1.53.0/ (older versions also follow the underscore filename pattern). Is there any particular reason for doing this? I suspect that it might cause problems to scripts looking for a specific pattern for the boost tar file and/or directory. All the best, - m.

2 1

[functional/hash] Interface-breaking changes to hash_combine
by Joaquin M Lopez Munoz 29 Jul '14

29 Jul '14

Hi, There's been a number of internal changes to the implementation of boost::hash_combine during this year, with the result that the documented procedure: http://www.boost.org/doc/html/hash/reference.html#boost.hash_combine namely, seed ^= hash_value(v) + 0x9e3779b9 + (seed << 6) + (seed >> 2), is no longer followed in all cases. This is a backwards compatibility breach --at the very least I think it should be documented. Best, Joaquín M López Muñoz Telefónica

3 2

News about proposed Boost.Application library
by Matus Chochlik 29 Jul '14

29 Jul '14

On Tue, Jul 29, 2014 at 9:39 AM, Klaim - Joël Lamotte <mjklaim(a)gmail.com> wrote: > > It would be nice if get_symbol returned a smart pointer that contained a > shared_ptr to the library. When all such references are released, the > library can be unloaded. > > > > I disagree. In my experience it would be more useful if it contained a > weak_ptr to the library, with a centralised system keeping all loaded > libraries alive and allowing the used to unload the library explicitely. > The get_symbol return type would then be testable. > That way it is easier to find issues related to plugins and its still > possible for the user to prevent these issues at runtime. > +1

1 0

[geometry] convex_hull: dispatch implementation details
by Jeremy Murphy 29 Jul '14

29 Jul '14

Hi, just wondering why boost::geometry::convex_hull is implemented with that dispatch-struct-apply business? Is it because of the two forms of convex_hull: output reference and output iterator? I'm writing a concave_hull implementation, so I'm wondering whether I should emulate the conventions in the convex_hull implementation. Thanks, cheers. Jeremy

2 3

Release branch will be closing Monday night.
by Marshall Clow 28 Jul '14

28 Jul '14

We will be “closing” the release branch late Monday night (Pacific Daylight time) in preparation for building a 1.56.0 release candidate on Tuesday morning. [ Actually, we’re just going to stop the automatic merging to the super-project, but … ] Please refrain from committing to the “master” branch of your libraries after 11:59 Monday night. (unless you have specific permission from the release managers) Thank you. — Marshall

4 5

Merging Pull Requests
by Axel Ismirlian 28 Jul '14

28 Jul '14

I have made some pull requests in several submodules of boost regarding compatibility changes for AIX several weeks ago. Is there any way to get them more attention? I have received no indication on most of them that they have been seen by their corresponding maintainers. Sincerely, -Axel

3 2

[wave] preprocess fails using b2
by Fletcher, John P 28 Jul '14

28 Jul '14

I have been using b2 to build the preprocessed files for boost phoenix. When I try to do this it now fails with a failure to build thread.cpp "g++-4.6" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pedantic -pthread -Wextra -Wno-long-long -Wno-variadic-macros -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO -DBOOST_THREAD_POSIX -DBOOST_WAVE_SUPPORT_THREADING=0 -DNDEBUG -I"../../.." -c -o "../../../bin.v2/libs/thread/build/gcc-4.6/release/link-static/threading-multi/wavetool-on/pthread/thread.o" "../../../libs/thread/src/pthread/thread.cpp" ../../../boost/ref.hpp:32:25: error: redefinition of â€˜class boost::reference_wrapper<T>â€™ ../../../boost/core/ref.hpp:59:25: error: previous definition of â€˜class boost::reference_wrapper<T>â€™ ../../../boost/ref.hpp:56:75: error: redefinition of â€˜template<class T> const boost::reference_wrapper<T> boost::ref(T&)â€™ ../../../boost/core/ref.hpp:131:74: error: â€˜template<class T> const boost::reference_wrapper<T> boost::ref(T&)â€™ previously declared here . It looks as though it is picking up two copies of the header file ref.hpp. This is the case with both gcc 4.6 and also gcc 4.9.0 It is not clear to me where the source file is coming from. At the moment all the libraries in my modular boost are checked out as develop. This is meaning that I cannot update my preprocessed files. Please advise me what to do. Thanks John

5 6

[1.56.0] Beta 1 Available
by Marshall Clow 28 Jul '14

28 Jul '14

Boost release 1.56.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.56.0.beta.1/ This release contains 2 new libraries: * Align: Memory alignment functions, allocators, and adaptors, from Glen Fernandes. * Type_Index: Runtime/Compile time copyable type info, from Antony Polukhin. Modularization Boost version control has migrated to a system using git submodules. This shouldn't make too much of a difference to users, although the directory structure is now a bit different. Parts of some libraries have been moved into different modules, and several new modules have been extracted from existing code. All header paths should remain the same. The new modules are: * Assert: Customizable assert macros. Maintained by Peter Dimov. * Core: Core utilities used by other libraries, with minimal dependencies. Maintained by Peter Dimov, Glen Fernandes and Andrey Semashev. * Lexical_Cast: General literal text conversions, such as an int represented a string, or vice-versa, from Kevlin Henney. * Throw_Exception: A common infrastructure for throwing exceptions from Boost libraries, from Emil Dotchevski. * Winapi: Windows API declarations without <windows.h>, for internal Boost use. For details of what's in the release, see http://www.boost.org/users/history/version_1_56_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

8 17

Boost.Any and RTTI
by Chris Glover 27 Jul '14

27 Jul '14

Hi, I need a Boost.Any like facility that doesn't depend on RTTI, so I patched Boost.Any to utilize Boost.TypeIndex if BOOST_NO_RTTI is defined. The diff is available here; https://github.com/cdglove/any/commit/7188b13909a061495ef31f979b55f9779a9e9… Is there any interest in merging this into mainline? Or is someone working on a more correct patch than this? Thanks, -- chris

2 3

[GSoC] Scheduled Executors beta 1 release
by Ian Forbes 27 Jul '14

27 Jul '14

Hello, I am working on implementing scheduled executors as part of GSoC 2014 and am ready to announce my beta 1 release. For more information on my project please see my original proposal at www.cs.mcgill.ca/~iforbe All my work is currently on this branch of boost.thread. https://github.com/BoostGSoC14/boost.thread.executors . I have written a fairly extensive README about design and implementation on this page. Basically a scheduled executor is an executor which guarantees that a certain task won't be run before a certain time point. Its main use cases would be things such as periodically reloading a file, pushing updates, flushing data, and polling. It has a thread safe priority queue that store tasks (currently std::function) along with a chrono::time_point. The priority queue is ordered so that the task with the least time point (closest to time 0) is at the front. There is an abstract class scheduled_executor that deals with all the enqueue methods to the executor. The ctor is protected. There are no virtual members. There are 2 subclasses. scheduled_thread_pool and scheduling_adaptor. These add dequeuing logic to the scheduled_executor by means of a worker thread(s). I'm mostly interested in people reading this part of the README: https://github.com/BoostGSoC14/boost.thread.executors#possible-changes--rfcs This details possible changes that could be made and I would like some feedback on them as these items have both pros and cons. Please provide your feedback and I will to my best to address your questions and concerns. Thanks, Ian

4 13

Portable robust mutex an another try...
by Ladislav Sopko 27 Jul '14

27 Jul '14

Hello, I did try to continue with */Ion Gaztanaga's /*idea of portable robust mutex. I post my code and considerations in codereview. http://codereview.stackexchange.com/questions/57083/portable-c-boostiterpro… I hope to find some one to discuss about. thx -- Sopko Ladislav 3D Informatica, Via Speranza 35, 40068, S.Lazzaro di Savena - Bologna, Italy Tel: +39051450844 | Fax: +39051451942 WWW: http://www.3di.it Documentation: https://intra.3di.it/manuali/ - http://wiki.3di.it FTP: ftp://ftp@ftp.3di.it, Download:/3di, Upload:/incoming **** Informativa Privacy - Ai sensi del D. Lgs n. 196/2003 (Codice Privacy) si precisa che le informazioni contenuti in questo messaggio sono riservate e ad uno esclusivo del destinatario. Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. Privacy Information - This message, for the D. Lgs m. 196/2003 (Privacy Code), may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addessee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thanks you for your cooperation. --

4 4

Donation
by Avihay Eyal 27 Jul '14

27 Jul '14

Hi, my company uses boost, and we would like to donate money. Is it possible? If so, then how? Thanks.

2 1

Permission to merge to master during release
by Glen Fernandes 26 Jul '14

26 Jul '14

The small change: https://github.com/boostorg/smart_ptr/commit/88f0a98d71 Renaming identifier of a member function from "free" to anything that is not "free" to compensate for _CRTDBG_MAP_ALLOC users in MSVC. (A colleague at Microsoft reported this to me today; he tried the 1.56.0 beta with MSVC and with _CRTDBG_MAP_ALLOC defined. It doesn't like a member function named "free"). Glen

4 4