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

Migrating www.boost.org to another server
by DongInn Kim 17 Jun '13

17 Jun '13

Hi, The CREST is planning to move all the boost services that OSL/CREST has provided to another server. All the services in the current OSL/CREST server are: - Web services: www.boost.org boostcon.boost.org svn.boost.org/svnmanager svn.boost.org/trac/boost beta.boost.org - Subversion, trac, and SVNManager - Mailinglist mailman hypermail First, we would like to migrate www.boost.org and beta.boost.org which are not dependent on any other services and domains at all. The data of www.boost.org and beta.boost.org can be simply moved but I need someone's help who can switch the domain record to make these two hostnames point to the new server. Who can I talk to about this domain migration? I will setup another schedule for the next migrations and I do not have any particular lists yet but probably the rest of web services and Subversion would be the candidate. We will see. Regards, -- - DongInn

4 7

[phoenix] Using Phoenix lambdas on top of custom Proto expressions
by Denis Demidov 17 Jun '13

17 Jun '13

Hello, I am working on VexCL (https://github.com/ddemidov/vexcl) - a vector expression template library for OpenCL. I have recently added support for automatic generation of OpenCL kernels from generic functors (description of the feature: https://github.com/ddemidov/vexcl#function-generator) In order to implement this, I pass the instances of vex::symbolic<T> class to the given functor. vex::symbolic<T> dumps to output stream any arithmetic operations it is being subjected to, and that's how I am able to construct the OpenCL kernel source. The symbolic<T> class is of course a Boost.Proto terminal. Now, it seems natural to use Boost.Phoenix to provide the generic functors for the function generator. And indeed it is possible with simple expressions (see https://github.com/ddemidov/vexcl/blob/a95dfdd68/tests/generator.cpp#L124) However, if I try to bring cmath functions overloads from <boost/phoenix/stl/cmath.hpp> and use those ( https://github.com/ddemidov/vexcl/commit/b95da14e51) I get compilation errors. The reason apparently is that boost::phoenix_impl::<function>_impl assumes that result of <function>(expr) has the same type as expr itself. This of course is not true if expr is a Boost.Proto expression. Everything works as intended with the following patch: --- a/cmath.hpp +++ b/cmath.hpp @@ -25,11 +25,11 @@ namespace boost { struct result<This(BOOST_PHOENIX_A(n))> \ { \ typedef \ - typename proto::detail::uncvref<A0>::type \ + decltype( name(typename proto::detail::uncvref<A0>::type()) ) \ type; \ }; \ template<BOOST_PHOENIX_typename_A(n)> \ - A0 operator()(BOOST_PHOENIX_A_const_ref_a(n)) const { \ + auto operator()(BOOST_PHOENIX_A_const_ref_a(n)) const -> decltype( name(BOOST_PHOENIX_a(n)) ) { \ using namespace std; \ return name(BOOST_PHOENIX_a(n)); \ } \ I understand this is unacceptable in its current form (because it uses c++11 features), but I could not do this in terms of e.g. boost::result_of. May be someone has a better idea of how to implement this? -- Best regards, Denis

1 0

[thread] Use of synchronized_value<> member in a constructor
by Klaim - Joël Lamotte 17 Jun '13

17 Jun '13

I am using now Boost 1.54.0 Beta (r84749). I am writting code similar to the following (but a bit more complex) : struct SequenceInfo { SequenceId id; ProjectId project_id; std::string name; //.... }; class Sequence { boost::synchronized_value<SequenceInfo> m_info; public: explicit Sequence( SequenceId new_id, SequenceInfo info ) : m_info( std::move(info) ) { m_info->id( new_id ); // mutex lock } // ... }; My current understanding of concurrent access practice is that it is not necessary to use synchronization mechanisms associated to member objects manipulated into a constructor, because it can happen on only one thread. If I am correct, then the lock of the synchronized_value is unnecessary. I suspect that there might be other cases like this one where the object responsable for the synchronized object should be able, rarely, to access the object unsafely. Suggestion: add an unsafe access to the object, in a very visible way. m_info.unsafe_access().id( new_id ); OR m_info.unsafe_access()->id( new_id ); // using a smart pointer which checks if safe accesses have been done inbetween and throw if it is the case? or any other checks detecting potential error It looks like it would allow avoiding cost where it could be avoided using a mutex manipulated manually. Any thoughts on this? Joel Lamotte

2 7

[1.54] [thread] MSVC build broken
by Andrey Semashev 16 Jun '13

16 Jun '13

Hi, I've noticed that my Boost.Log tests on MSVC are failing massively. The build log hints that Boost.Thread might be the culprit, and its tests are also failing on MSVC with the following error: ..\boost/thread/future.hpp(1127) : error C2248: 'boost::unique_lock<Mutex>::operator =' : cannot access private member declared in class 'boost::unique_lock<Mutex>' with [ Mutex=boost::mutex ] ..\boost/thread/lock_types.hpp(110) : see declaration of 'boost::unique_lock<Mutex>::operator =' with [ Mutex=boost::mutex ] This is happening on release branch. Could this be fixed?

4 10

[test] resolution of test time information
by Alexander Kjäll 16 Jun '13

16 Jun '13

Hi I'm new to the boost test library and it seems to fill my needs of a testing framework quite well. One thing that i haven't managed to figure out is if it's possible to increase the resolution of the timekeeping information, it currently seems to be reported with a resolution of 10 milliseconds. Is it possible to reduce that somehow? best regards Alexander Kjäll

1 0

[c++11]
by Sid Sacek 15 Jun '13

15 Jun '13

This was probably discussed many times already, but I seem to not have been paying close enough attention. Maybe someone can point me to the discussions in the archives... With all of the cool new language features of C++11, am I correct in assuming that boost library developers have no real opportunity to use any of it in order to be backwards compliant with all the older standard? I realize there are many boost equivalents already in place, but when would it become permissible to use native C++11 syntax? Thanks, -Sid

7 8

[optional][thread] Returning a future in an optional fails
by Klaim - Joël Lamotte 14 Jun '13

14 Jun '13

I just hit this using VS2012/boost 1.54 beta. #include <boost/optional.hpp> #include <future> boost::optional< std::future<void> > top() { return std::async( []{ int i=0; ++i; } ); } int main() { auto opt = top(); } Error: 1>E:\Projects\SDK\boost\boost\include\boost-1_54\boost/optional/optional.hpp(347): error C2248: 'std::future<void>::future' : cannot access private member declared in class 'std::future<void>' 1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\future(1238) : see declaration of 'std::future<void>::future' 1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\future(1200) : see declaration of 'std::future<void>' 1> E:\Projects\SDK\boost\boost\include\boost-1_54\boost/optional/optional.hpp(346) : while compiling class template member function 'void boost::optional_detail::optional_base<T>::construct(const std::future<void> &)' 1> with 1> [ 1> T=std::future<void> 1> ] 1> E:\Projects\SDK\boost\boost\include\boost-1_54\boost/optional/optional.hpp(231) : see reference to function template instantiation 'void boost::optional_detail::optional_base<T>::construct(const std::future<void> &)' being compiled 1> with 1> [ 1> T=std::future<void> 1> ] 1> E:\Projects\SDK\boost\boost\include\boost-1_54\boost/optional/optional.hpp(501) : see reference to class template instantiation 'boost::optional_detail::optional_base<T>' being compiled 1> with 1> [ 1> T=std::future<void> 1> ] 1> E:\Projects\Art_Of_Sequence\repos\aos-all\tool\aosdesigner\backend\test\workspace.cpp(30) : see reference to class template instantiation 'boost::optional<T>' being compiled 1> with 1> [ 1> T=std::future<void> 1> ] I also tried with http://coliru.stacked-crooked.com/ gcc4.8 (but I don't know the boost version) and got a similar error. I first hit this with boost::future but it don't seem to be the problem as it generate the same error. My question is: does std/boost::future don't match the requirements to be an optional value? Or is this an error I should log? Joel Lamotte

2 1

link to old TR1 draft on boost.org
by Jonathan Wakely 14 Jun '13

14 Jun '13

The Boost home page links to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf but that draft was replaced by N1836.

2 1

Future of Boost.Signals
by Marshall Clow 13 Jun '13

13 Jun '13

Doug Gregor has indicated to me that he is not able to continue with the development/maintenance of Boost.Signals. [ This is not a surprise, the last significant change to the library was back in 2004. ] Fortunately, Frank Hess' Signals2 library is going strong, and he has a porting guide for people currently using Boost.Signals at: http://www.boost.org/doc/html/signals2/api_changes.html#signals2.porting For the upcoming 1.54 release, I have added notes to this effect to the Boost.Signals documentation, and added a warning to <boost/signals.hpp>. The warning states: Boost.Signals is no longer being maintained and is now deprecated. Please switch to Boost.Signals2. To disable this warning message, define BOOST_SIGNALS_NO_DEPRECATION_WARNING Note: There have been no code changes to Boost.Signals. All code that uses it will continue to work. -- 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

1 0

Tips to fix boost::asio::windows::random_access_handle which is seriously broken
by Niall Douglas 13 Jun '13

13 Jun '13

Dear Boost, The forthcoming GSoC Boost.AFIO library has found a problem with boost::asio::windows::random_access_handle in that it appears to clamp buffer sizes to 64Kb and not increment overlapped offsets during multi-buffer reads and writes, and which is reported at https://svn.boost.org/trac/boost/ticket/8669. These are desirable features for network i/o, not so for file i/o. As my work on the existing code base which Paul is porting to Boost is now complete and purring beautifully on POSIX, I'm thinking I might as well go fix the Boost.ASIO Windows IOCP problem. Before I begin, can I ask here if anyone else has done some work on this topic from which I might be able to borrow? The thread at http://comments.gmane.org/gmane.comp.lib.boost.asio.user/3676 suggests that if I use async_write_some() then I can bypass the 64Kb clamp using "my own completion condition". I'm thinking that boost::asio::windows::random_access_handle really ought to actually implement random access, so rather than hacking around the problem, fixing boost::asio::windows::random_access_handle is better. My thanks in advance, Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0