- Boost - lists.preview.boost.org

Re: [boost] [c++11]
by Niall Douglas 17 Jun '13

17 Jun '13

> That depends on what you consider supported by Boost. A lot of the > courtesy support for the native compilers for many OSes out there seems > to be dying out. If I may be blunt though, if big libraries like Boost don't show up vendor provided compilers as falling short on standards compliance, then there is very little incentive for those vendors to fix their compilers. In other words, it goes both ways. > I used to see Boost as an empowering library, enhancing and evening out > the playing field among the compilers out there. > > Some seem to see it as a playground to gain recognition and fast-track > things into the coming standard libraries, instead of producing > something usable in the real world. > > I guess it's losing the goal and aim I perceived, if it ever had it to > begin with. To me, it feels like a betrayal from the library I have > spent many manhours supporting. > > I've been on this rant before on the lists, in the big sprawling > discussions about the feasibility of a Boost 2.0, but it seems nothing > was learned then, and I don't expect anything to be learned going > forward either. > > As for limiting Boost authors, for leaf libraries that end users can > avoid, sure, there might not be too much harm. It's creeping into the > very core libraries as well, which _does_ bother me, as it can render > whole swaths of the library utterly unusable. > > In the end, we need a definitive statement from whatever cabal is > controlling Boost, so we don't get these kinds of discussion > resurrections every few months. All this causes is a lack of faith in > the project. Equally, it's not like Boost is hugely commercially developed like other open source projects: it's mostly volunteer driven. And it's real tough to come along to people's free time and tell them they have to target compilers written more than a decade ago, and if they don't their commits won't be allowed or will get rolled back. I'll be blunt here: taking off my corporate job hat and putting back on my old consulting hat, I'd say it simply: you'll get ~ 90% of the C++ user base support from my open source code for free. If you want more for your niche technology Y, my rates start at $200/hour. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

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