- Boost - lists.boost.org

Re: [boost] Some patches to remove obsolete MSVC version checks
by Stephen Kelly 26 Sep '13

26 Sep '13

On 09/13/2013 01:35 PM, Stephen Kelly wrote: > Hi, > > I've attached patches to remove or simplify some ifdefs for MSVC > versions which are now obsolete. > > This is a followup to this thread: > > http://thread.gmane.org/gmane.comp.lib.boost.devel/243094 > (Removing old config macro and increasing compiler requirements., > 2013-07-29) > > The patches are most easily applied locally and reviewed with a git-svn > checkout and git am. > > I'll also apply to get SVN access so I can commit patches myself. FYI, I've started cherry-picking, re-reviewing and committing these patches. I'll keep the patches small and single-issue. I would appreciate post-commit review from anyone for any of them, as some of the ifdef chains are complex. Thanks, Steve.

2 2

BoostPro closing the doors and needing volunteers
by munsingh 25 Sep '13

25 Sep '13

Hello Boost Maintainers, I observed that BoostPro have closed doors and have made the project open source. I would like to volunteer for maintaining and enhancing the pre-build binaries and sources for boost pre-built installers. Kindly let me know what all is desired from a person who wishes to take up this activity. Thanks & Regards, Manish -- May the force be with you

2 1

VC12 RC: Compiler crash when mixing boost::synchronized_value, Boost.ptree and uniform initialization.
by Klaim - Joël Lamotte 25 Sep '13

25 Sep '13

Just for information, if that can help, I just reported this bug that I can only reproduce using boost::synchronized_value<boost::property_tree::ptree>::operator->() It's obviously a compiler problem but it might help adapting Boost code it if it is not fixed in time for VS2013 release: https://connect.microsoft.com/VisualStudio/feedback/details/802157/compiler… As said in the comments, I didn't find how to reproduce it in a simpler way.

1 0

[thread] synchronized_value: value and move semantics
by Vicente J. Botet Escriba 24 Sep '13

24 Sep '13

Hi, boost::synchronized_value (not released yet [1][2][3]) is based on [4]. See below part of this paper adapted to the Boost.Thread interface. Currently boost::synchronized_value is in addition Copyable and Swappable. I was wondering if it is worth adding value and move semantics to synchronized_value. Making it EqualityComparable, LessThanComparable and Movable if the underlying type satisfy these requirements will allow to store them on a Boost.Container/C++11 container. Do you see something completely wrong with this addition? Has some of you had a need for this? Could you share the context? Best, Vicente [1] https://svn.boost.org/svn/boost/trunk/boost/thread/synchronized_value.hpp [2] https://svn.boost.org/svn/boost/trunk/libs/thread/example/synchronized_valu… [3] https://svn.boost.org/svn/boost/trunk/libs/thread/example/synchronized_pers… [4] "Enforcing Correct Mutex Usage with Synchronized Values" by Anthony Williams http://www.drdobbs.com/cpp/enforcing-correct-mutex-usage-with-synch/2252002… ------------- [section The Problem with Mutexes] The key problem with protecting shared data with a mutex is that there is no easy way to associate the mutex with the data. It is thus relatively easy to accidentally write code that fails to lock the right mutex - or even locks the wrong mutex - and the compiler will not help you. std::mutex m1; int value1; std::mutex m2; int value2; int readValue1() { boost::lock_guard<boost::mutex> lk(m1); return value1; } int readValue2() { boost::lock_guard<boost::mutex> lk(m1); // oops: wrong mutex return value2; } Moreover, managing the mutex lock also clutters the source code, making it harder to see what is really going on. The use of synchronized_value solves both these problems - the mutex is intimately tied to the value, so you cannot access it without a lock, and yet access semantics are still straightforward. For simple accesses, synchronized_value behaves like a pointer-to-T; for example: boost::synchronized_value<std::string> value3; std::string readValue3() { return *value3; } void setValue3(std::string const& newVal) { *value3=newVal; } void appendToValue3(std::string const& extra) { value3->append(extra); } Both forms of pointer dereference return a proxy object rather than a real reference, to ensure that the lock on the mutex is held across the assignment or method call, but this is transparent to the user. [endsect] [/The Problem with Mutexes] [section Beyond Simple Accesses] The pointer-like semantics work very well for simple accesses such as assignment and calls to member functions. However, sometimes you need to perform an operation that requires multiple accesses under protection of the same lock, and that's what the synchronize() method provides. By calling synchronize() you obtain an strict_lock_ptr object that holds a lock on the mutex protecting the data, and which can be used to access the protected data. The lock is held until the strict_lock_ptr object is destroyed, so you can safely perform multi-part operations. The strict_lock_ptr object also acts as a pointer-to-T, just like synchronized_value does, but this time the lock is already held. For example, the following function adds a trailing slash to a path held in a synchronized_value. The use of the strict_lock_ptr object ensures that the string hasn't changed in between the query and the update. void addTrailingSlashIfMissing(boost::synchronized_value<std::string> & path) { boost::strict_lock_ptr<std::string> u=path.synchronize(); if(u->empty() || (*u->rbegin()!='/')) { *u+='/'; } } [endsect] [/Beyond Simple Accesses] [section Operations Across Multiple Objects] Though synchronized_value works very well for protecting a single object of type T, nothing that we've seen so far solves the problem of operations that require atomic access to multiple objects unless those objects can be combined within a single structure protected by a single mutex. One way to protect access to two synchronized_value objects is to construct a strict_lock_ptr for each object and use those to access the respective protected values; for instance: synchronized_value<std::queue<MessageType> > q1,q2; void transferMessage() { strict_lock_ptr<std::queue<MessageType> > u1 = q1.synchronize(); strict_lock_ptr<std::queue<MessageType> > u2 = q2.synchronize(); if(!u1->empty()) { u2->push_back(u1->front()); u1->pop_front(); } } This works well in some scenarios, but not all - if the same two objects are updated together in different sections of code then you need to take care to ensure that the strict_lock_ptr objects are constructed in the same sequence in all cases, otherwise you have the potential for deadlock. This is just the same as when acquiring any two mutexes. In order to be able to use the dead-lock free lock algorithms we need to use instead unique_lock_ptr, which is Lockable. synchronized_value<std::queue<MessageType> > q1,q2; void transferMessage() { unique_lock_ptr<std::queue<MessageType> > u1 = q1.unique_synchronize(boost::defer_lock); unique_lock_ptr<std::queue<MessageType> > u2 = q2.unique_synchronize(boost::defer_lock); boost::lock(u1,u2); // dead-lock free algorithm if(!u1->empty()) { u2->push_back(u1->front()); u1->pop_front(); } } [endsect] [/Operations Across Multiple Objects]

6 19

Re: [boost] [Boost-users] cross-compilation x86_64-w64-ming32: undefined reference to `InterlockedIncrement'
by Frédéric Bron 24 Sep '13

24 Sep '13

So I eventually managed to fix the issue with interlocked.hpp and mingw-w64: both i686 and x86_64 now work. Attached is a patch against 1.54.0. Is it possible to include this in 1.55.0? Regards, Frédéric

3 17

Is there any interest in a library for application : Boost.Application, new version: Boost.Application_beta_3a_release_2
by Renato Forti 23 Sep '13

23 Sep '13

Hi all, The docs and lib are updated! Please, send your comments. http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.html PS: I want to take and ask for help, if any native english speaker can help me with the documentation! Please, contact: re.tf <at> acm.org Thanks

5 8

Referencing Boost.Iostreams in the documentation of a non-boost library
by Gene Panov 23 Sep '13

23 Sep '13

Boost Experts, I am a fan of Boost.Iostreams and I am referencing them several times in the documentation of a little library that I wrote and posted on Google Code under "New BSD license" (https://code.google.com/p/async-ostream/) Do I need to provide a full URL or copyright information or anything else to make such reference to Boost.Iostreams legally sound? Or shall I just switch to use Boost Software License instead to keep it simple? Thanks! Gene

3 2

Functionality for part 7(a) of Boost.IOStreams Roadmap
by Gene Panov 23 Sep '13

23 Sep '13

Boost Experts, I think I possibly addressed the "output" part of requirement 7(a) (Support for asynchronous and non-blocking I/O :: asio compatibility) from the Iostreams Roadmap https://svn.boost.org/trac/boost/wiki/IostreamsRoadmap in this library https://code.google.com/p/async-ostream/ Do you think it addresses that requirement from the roadmap? If yes, does it make sense if I make a patch for Boost.Iostreams to include those five files? Regards, Gene

1 0

[predef] [git] Do the tests need an explicit <dependency>
by Steven Watanabe 22 Sep '13

22 Sep '13

AMDG The property <dependency>$(BOOST_PREDEF_INCLUDE_ROOT)/boost/predef.hpp interferes with testing under the git layout, because this header is generated as part of the build. Is there a reason for it? The dependency should be found by the #include scanner. In Christ, Steven Watanabe

2 1

[config] Visual C++ 2013 RC support - variadic template failures
by Beman Dawes 21 Sep '13

21 Sep '13

I updated boost/config Visual C++ support yesterday to add Visual C++ 2013 RC support. But Mat Berchtold reported that signals2 tests then started to fail. I confirmed that 2013 RC tests were failing for signals2 and several of its dependencies, and narrowed it down to variadic templates so reverted to defining BOOST_NO_CXX11_VARIADIC_TEMPLATES for 2013 RC. --Beman

3 6