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

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

18 Jun '13

> > I should quickly explain why rvalue ref support is so important to proposed > > Boost.AFIO: it's a 100% batch API and therefore takes in batches of things > > to do and returns out batches of results. That implies lots of passing > > sequences of things around in STL containers, which without rvalue refs are > > not cheap to copy. Therefore while we could get the library working on > > Maybe BOOST_ASIO_MOVE_ARG (in boost/asio/detail/config.hpp) will work > for you. I don't understand how that makes std::vector<> or any other STL container suddenly magically start not copy constructing its contents on C++03 compilers. struct async_io_op has both rvalue and const lvalue copy and assignment constructors. It's left up to the compiler and STL container implementation to decide when and where to use them. I agree we should be using more std::move() to help the compiler where it needs it, but all performance tuning is being left till after the Boost import. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

2 1

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

18 Jun '13

> 2013/6/14 Sid Sacek <ssacek(a)securewatch24.com>: > <...> > > Sounds like it's not really worth the effort and simply just stick to the old style. > > Stick to the old style. Add #ifndef'ed C++11 specific features if they add > functionality or improve performance much. Boost libraries are tested using > C++11 and C++03 on different compilers and works good in all situations. Speaking of which, I was going to ask this list about the minimum compiler requirements for proposed GSoC Boost.AFIO, so now is as good a time as any. The existing code base being prepared for entry into Boost is pure C++11, or at least as much C++11 as is provided by the Nov 2012 CTP experimental MSVC compiler and therefore easily supported by GCC 4.6 and clang 3.x. The variadic templates used probably can be swapped out easily enough with Boost Preprocessor generators. The very extensive use of C++11 only library features could probably be replaced with Boost equivalents in most cases, though we really do need a fully C++11 functional std::exception_ptr rather than Boost's limited boost::exception_ptr. The thing we probably can't replace without major surgery is rvalue reference usage. It's used very extensively. Moreover, performance without rvalues would truly suck. So here's the question: is C++03 compiler and C++03 TR1 standard library support still an absolute, unnegotiable requirement for a library to become an official part of Boost? Or can we at least require rvalue reference support as a minimum? Or do we add a new category to Boost: some bits of C++11 requiring libraries? We're going to have to do this eventually anyway. Niall

12 20

[multiprecision] Are these types suitable as numeric types for unit tests?
by Daryle Walker 18 Jun '13

18 Jun '13

I'm writing new numeric types, and my unit tests use MPL lists of numeric types. I usually use stuff like int, unsigned, and double, but now I'm adding cpp_int and cpp_dec_float_50. Those types were OK when I was just doing type equalities and sizeof checks. Now I'm doing tests that use objects of those types and I'm getting problems. //==== typedef boost::mpl::list<int, unsigned, cpp_int> test_integer_types; typedef boost::mpl::list<double, cpp_dec_float_50> test_floating_types; //... BOOST_AUTO_TEST_CASE_TEMPLATE( test_complex_component_access1, T, test_integer_types ) { typedef complex_it<T, 0> real_type; typedef complex_it<T, 1> complex_type; real_type a; real_type const & aa = a; complex_type b; complex_type const & bb = b; a[ 0 ] = 6; BOOST_CHECK_EQUAL( a[0], T(6) ); BOOST_CHECK_EQUAL( T(6), aa[0] ); b[ 0 ] = 5; b[ 1 ] = 7; BOOST_CHECK_EQUAL( b[0], T(5) ); BOOST_CHECK_EQUAL( T(5), bb[0] ); BOOST_CHECK_EQUAL( b[1], T(7) ); BOOST_CHECK_EQUAL( T(7), bb[1] ); } //==== I'm getting warnings about integer overflow. The problem is at Line 59 of boost/test/tools/detail/print_helper.hpp. It sets an output stream's precision based on the digits given by std::numeric_limits. //==== BOOST_AUTO_TEST_CASE_TEMPLATE( test_complex_component_access2, T, test_floating_types ) { typedef complex_it<T, 0> real_type; typedef complex_it<T, 1> complex_type; real_type a; real_type const & aa = a; complex_type b; complex_type const & bb = b; a[ 0 ] = 6.0; BOOST_CHECK_CLOSE( a[0], T(6.0), 0.1 ); BOOST_CHECK_CLOSE( T(6.0), aa[0], 0.1 ); b[ 0 ] = 5.5; b[ 1 ] = -7.0; BOOST_CHECK_CLOSE( b[0], T(5.5), 0.1 ); BOOST_CHECK_CLOSE( T(5.5), bb[0], 0.1 ); BOOST_CHECK_CLOSE( b[1], T(-7.0), 0.1 ); BOOST_CHECK_CLOSE( T(-7.0), bb[1], 0.1 ); } //==== This time it's an error, at Line 59 of boost/test/tools/floating_point_comparison.hpp. There no (close enough) matching function for "fpt_abs" from some "boost::multiprecision::detail::expression<..." type. (It was truncated by the display. I don't know how to get a clean print-out of errors from Code::Blocks.) I'm guessing the expression template setup is screwing things up. Daryle W.

6 25

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

17 Jun '13

> > We can work around the lack of variadic templates, and therefore > > support vanilla VS2012 if peer review demands it. Of course VS2012 > > won't make binaries which can run on Windows XP :( so maybe VS2010 > > support will also be demanded by peer review. If it is, we'll do what is required > to meet VS2010. > JFYI: the VS2012 Update 1 can build binaries which can run on WinXP. You just > need to specify the v110_xp toolset in the project options. Apologies, I had skim read the VS2012 update announcement when it happened where it used the phrase "This new platform toolset points to a repackaged version of the Windows 7 SDK shipped in Visual Studio 2010 instead of the Windows 8 SDK" but I had missed the phrase "but uses the same Visual Studio 2012 compiler". As a result, I thought they had basically packed up the VS2010 build environment for VS2012 and that they therefore were equivalent. Mea culpa. BTW, and purely for information, I found that if you build your VS2012 Nov 2012 CTP app as a DLL, and then write a tiny shim program in VS2010 which loads in that DLL, all appeared to work okay on Windows XP. I didn't test that hugely at the time, but it did work for me to get variadic template capable MSVC binaries running on XP. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

[New][Multiprecision] Getting errors while writing hypercomplex classes.
by Daryle Walker 17 Jun '13

17 Jun '13

I've banged out (yet another) complex number class at <https://github.com/CTMacUser/Complex>. The current commit has an SHA of "b866cda91ccdb4aa87c199c6d9e7c776fee61bcc." Right now, I'm writing this code on a 32-bit Windows 8 system using Code::Blocks with a packaged MinGW GCC 4.7 by TDM. In many of the incremental changes, I ran into internal compiler errors. I don't know if my code is too unusual or it's the compiler. I'm asking if you guys can check out the code with other compilers (GCC 4.7 besides MinGW/TDM, GCC 4.8, Clang 3.x, non-Windows, etc.) so we can figure out what bug goes where. There are two class templates: - boost::math::complex_it<Number, Rank> - boost::math::complex_rt<Number, Rank> "Number" is a Regular type that supports math operations plus Boolean conversions. "Rank" is the Cayley-Dickson hypercomplex level. Use 0 as a shell for real numbers, 1 for regular complex numbers, 2 for quaternions, 3 for octonions, etc. The "complex_it" class template stores all the components directly in an array with length 1ULL << Rank ("i" is for "iterative"). The "complex_rt" class template stores an array of 2 objects of the previous level ("r" is for "recursive"), except for the partial-specialized base case which stores one component. The two templates support nearly the same interface. - Static interface * using value_type = Number * rank = Rank * static_size = 1ULL << Rank * using barrage_type = complex_?t<Number, Rank - 1> (or self when Rank == 0) - Construction * Complex_type a; // random garbage bits * Complex_type b{}; // zero-fill * Complex_type c{ r }; // real conversion * Complex_type d{ r, i, ... }; // real list * Complex_type e{ Complex_type<ConvertibleNumber, SameOrLowerRank>, ... }; * Complex_type f{ Complex_type<ConvertibleNumber, GreaterRank> }; // explicit * Complex_type g{ Other_complex_type<AnyNumber, AnyRank> }; // explicit * Complex_type h{ Complex_type<AnyNumber, AnyRank> }; // explicit * For [d], the total number components can't exceed static_size. * For [e], the combined number of components from the objects can't exceed static_size. * "ConvertibleNumber" uses implicit conversion, "AnyNumber" static_cast. * Conversions in [g] are both in complex_rt, a constructor and conversion-operator. * For [h], it excludes types in "AnyNumber" that would be covered by [e] and [f]. - Member functions * Boolean conversion operator (explicit) * "real" and "imag," inspector and mutator versions, just like std::complex (Don't use "imag" mutator when Rank == 0!) * "unreal" inspector, like boost::quaternion and octonion; plus a mutator version * Lower- and upper-halves of component list (called barrages) - complex_it uses inspector and mutator, like real/imag/unreal - complex_rt uses by-reference returns, const and mutable * operator [] for direct (by-reference) access to components - External operators * == * != * + (unary) * - (unary) * ~ (new, conjugation) * << (output) - Tuple interface (get, tuple_element, tuple_size) - Object support * begin (non-member, complex_it only) * end (non-member, complex_it only) * swap - Math * conj These spots cause internal-compiler errors: * https://github.com/CTMacUser/Complex/blob/master/include/boost/math/complex_ it.hpp#L753 * https://github.com/CTMacUser/Complex/blob/master/include/boost/math/complex_ rt.hpp#L593 * https://github.com/CTMacUser/Complex/blob/master/include/boost/math/complex_ rt.hpp#L599 use the comments to switch the code back and see if it works on your system. There were also problems using Boost.Multiprecision in the unit tests. I don't know if the problems are in Multiprecison, Test, MPL, or some interaction between them. The spots in "complex_it_test.cpp" and "complex_rt_test.cpp" that use the "test_builtin_types" alias were supposed to use "test_types," but the sample types from Multiprecision had MPL errors. Switch the types and see if they work on your system. Daryle W.

3 3

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

17 Jun '13

> > Actually it targets three compilers (+clang). I might add that > > Boost.ASIO only officially supports Windows, Linux, Solaris and OS X, > > and only the compilers MSVC7.1 or later and g++ 3.3 or later. Some > > would say that is a fairly narrow set in itself. > > That's not quite what I read here: > > http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/overview/implem > entation.html See for yourself at http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/using.html. I agree that perhaps that list, given the list you linked to, is now out of date. > And the compilers you mentioned as officially supported by ASIO actually cover > pretty much every compiler out there nowdays. > > Comparing that with your requirement of the compiler that has not even been > released, it doesn't look like AFIO portability level will be even remotely close to > that of ASIO. We can work around the lack of variadic templates, and therefore support vanilla VS2012 if peer review demands it. Of course VS2012 won't make binaries which can run on Windows XP :( so maybe VS2010 support will also be demanded by peer review. If it is, we'll do what is required to meet VS2010. > > Given that we knew that VS2012 would get variadic templates later this > > year (which it will in the form of VS2013), we decided to just go > > ahead with what > > C++11 features will be available to > 90% of C++ users by the end of 2013. > > That surely should satisfy the portability requirement, if not, then > > we'll work backwards until we reach > 95% of C++ users or > 99% if > > Boost peer review really, really wants it. > > I think your estimate of "> 90% of C++ users by the end of 2013" is much too > optimistic. People in corporate sector are very reluctant to update their > toolsets, so expect people trying to use your new library with 3-5 year old > compilers. I used the qualifier "available to" with purpose: I agree that a compiler may be available to > 90% of C++ users but for whatever reason those users do not avail of that compiler. FYI for my other open source I still get regular bug submissions for MSVC6 breakage due to my use of C++98 features, so I'm well aware what corporate is like. That said, this is a new greenfield library, and therefore no legacy compiler technology is inconvenienced by its compiler requirements. I might add that as C++ Now 2013 showed, there are quite a few new Boost libraries on their way which are C++11 only and will only ever be C++11 only: I saw presentations on new C++11 only versions of Boost.Proto and Boost.Spirit for example. > I know, C++11 has many fancy features and all, and I'm all for its adoption too. > But Boost also serves practical purpose, and if people can't use your library then > that just limits its usefulness. So unless you trying to make some academic work > here, the library should be more portable. If a corporate end user really, really wants the library working on their compiler toolset, they are always free to sponsor a port to that toolset. It's all open source. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

4 5

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

17 Jun '13

> > The existing code base being prepared for entry into Boost is pure > > C++11, or at least as much C++11 as is provided by the Nov 2012 CTP > > experimental MSVC compiler and therefore easily supported by GCC 4.6 and > clang 3.x. > > I hope that you do realize that the Nov12 CTP does not come with a go-live > license, nor is recommended for any human consumption. Meh. First preview of VS2013 is only a month away. Nov 2012 CTP is usefully broken in ways easy to work around (parser bugs) rather than broken in unhelpful ways (unreliable code generation). It fills a useful slot until VS2013 arrives later this year. > It seems quite odd to me to spend significant GSoC resources on making a library > that targets only two compilers, and assumedly a rather narrow set of OSes. Actually it targets three compilers (+clang). I might add that Boost.ASIO only officially supports Windows, Linux, Solaris and OS X, and only the compilers MSVC7.1 or later and g++ 3.3 or later. Some would say that is a fairly narrow set in itself. We'll be matching Boost.ASIO's official platform support, but adding official support for FreeBSD 10 with clang and libcxx. In truth though it ought to work on any OS providing a POSIX file i/o API with preadv() and pwritev() which is the majority (including Windows via its MSVCRT incidentally). You may find https://github.com/BoostGSoC/boost.afio/wiki/Status-of-proposed-Boost.AFIO of interest. There it tells you how to get started with the proposed library right now. > Was this C++11-only requirement part of the original project plan, and why > didn't anyone object to it then? Yes, it was an original plan requirement. Having full fat C++11 (esp. the C++11 standard library) to hand made the code and design *very* considerably simpler and *much* easier to read (and therefore maintain) - in fact, there is only 670 lines of active code. Judging from the presentations at C++ Now 2013, this simplification experience of pure C++11 is hardly unique: many presenters commented on just how much their pure C++11 new versions of Boost libraries were cleaner, simpler, faster to compile and faster performance, and hugely more maintainable. Given that we knew that VS2012 would get variadic templates later this year (which it will in the form of VS2013), we decided to just go ahead with what C++11 features will be available to > 90% of C++ users by the end of 2013. That surely should satisfy the portability requirement, if not, then we'll work backwards until we reach > 95% of C++ users or > 99% if Boost peer review really, really wants it. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

8 11

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

17 Jun '13

> > On 14 June 2013 17:21, Niall Douglas <ndouglas(a)blackberry.com> wrote: > >> So here's the question: is C++03 compiler and C++03 TR1 standard > >> library support still an absolute, unnegotiable requirement for a > >> library to become an official part of Boost? > > > > No. > > > > http://www.boost.org/development/requirements.html#Portability > > I suspect this may come down to the review ultimately: I can imagine that any > library that was C++11 only would have a hard time getting through review "as > is", *unless* there's a really compelling reason for it to be that way (and for > some libraries that may well be the case). However, I can also imagine a library > being developed as a C++11 only lib and only ported back to C++03 and/or less > capable compilers once it's stable (or vice versa). Thanks John: you're the only one who actually answered my question. I should quickly explain why rvalue ref support is so important to proposed Boost.AFIO: it's a 100% batch API and therefore takes in batches of things to do and returns out batches of results. That implies lots of passing sequences of things around in STL containers, which without rvalue refs are not cheap to copy. Therefore while we could get the library working on C++03, I'd imagine max IOPS would be awful as all those container copy constructors fire several times per API invocation. Right now max IOPS is about 80,000 which is awful, and that's *with* C++11. I'd expect that to be an order of magnitude slower without move construction. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

2 1

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

17 Jun '13

> 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. I misphrased myself here: nothing in this statement should be taken as meaning that I am available for consulting work at any hourly rate since I began employment at BlackBerry, and my consulting firm is indeed closed for new business with no prospect of reopening in the immediate future. I meant my original statement in the sense that wanting compatibility with some technology Y is something which can't be expected for free in open source. That includes legacy compilers. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

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

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

[Multiprecision] High-performance radix-2 floating-point back-end
by Aditya Jain 13 Jun '13

13 Jun '13

Hi This is my first post on the mailing list , so apologies if it doesn't follow any of the protocols. I was looking at GSoC projects this year for Boost and I am wondering if someone is working on a high-performance radix-2 floating-point back-end for Boost.Multiprecision. If not , I would be interested in doing this project .I am currently a Masters student interning at a tech company in Seattle but I would be able to devote 15-20 hours a week for this project. I have a fairly good background in C++ and numerical programming.So in case no else is working on it (for GSoC or otherwise ) , I would be really interested . If someone is already working on it, I would be interested in some other projects I could potentially work on . Looking forward to a reply. Regards -- Aditya Jain MS Computer Science (Machine Learning Track) Columbia University B.Tech, IIT Roorkee

4 4

ATTN: Boost GSoC mentors and students: Continuous Integration for GSoC thoughts
by Niall Douglas 11 Jun '13

11 Jun '13

Dear Boost, I spent the weekend experimenting with getting CI set up for the async file i/o library which will hopefully become Boost.AFIO through Paul's GSoC. I tried a number of free-for-open-source CI providers which integrate tightly with GitHub, and eventually settled with Travis CI. You can see the last commit CI results at https://travis-ci.org/ned14/TripleGit. As much as Travis CI has a primitive and clunky UI, unlike the other CIs it's based on snapshotting VMs with root privs which gives you unparalleled flexibility for testing config, so I was able to configure this to happen with each and every git push to github: 1. Test that code builds with GCC 4.6 and clang 3.2. 2. Test that unit and functional tests execute without error when built with GCC 4.6 and clang 3.2. 3. Run unit and functional tests with valgrind --tool=memcheck and test that no memory errors nor memory leaks occur with binaries built with GCC 4.6 and clang 3.2. 4. Install GCC 4.8 and compile everything using -fsanitize=thread (i.e. instrument using the port of clang's ThreadSanitizer v2 to GCC), then execute a full set of unit and functional tests looking for race conditions and if any, fail. You'll note I've marked that test as allowed to fail, because Boost v1.53 has a number of known race conditions when used as C++11 which are hopefully fixed in v1.54 :) Personally speaking, I think this depth and degree of CI is *invaluable* to modern software development practice. So the question becomes: are the Boost GSoC mentors and students interested in setting up CI for this year's GSoC projects, or at least the ones hosted on github at https://github.com/BoostGSOC? In case you're wondering how hard it is to set up Travis CI for your github project, you just need one file called .travis.yml. You can see the one I wrote at https://github.com/ned14/TripleGit/blob/master/.travis.yml. Thoughts? Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

4 7

[utility] [assert] Proposal for a new assert macro which stores the failed values ("informative assert")
by Viktor Sehr 11 Jun '13

11 Jun '13

I'd like some opinions about this assert implementation which I'd like to propose as an update of the old BOOST_ASSERT. Basically it stores the failed values next to the expression string, instead of just the expression string: "INFORMATIVE_ASSERT(5*5 < 2*2);" "5*5 < 2*2 | 25 | 4" "INFORMATIVE_ASSERT(std::vector<int>(10).size() == std::vector<int>(12).size());" "std::vector<int>(10).size() > std::vector<int>(12).size() | 10 | 12" Notes - If the class can't be serialized, the byte-data is logged instead. - It writes the values to the expression string in order to be compliant with any assert implementations Easy to read implementation available here: https://docs.google.com/file/d/0B69BCPzak52DcnF5dmhRRno3V2M/edit?usp=sharing Modified version of BOOST_ASSERT available here: https://docs.google.com/file/d/0B69BCPzak52DZW1oX1AtREM4eVU/edit?usp=sharing /Viktor (Reposting this as I posted it without labels one week ago)

4 13

Re: [boost] [1.54.0] Beta 1 Available
by Cromwell Enage 11 Jun '13

11 Jun '13

Hi, all. When calling the merge() member function of a boost::heap::d_ary_heap, is the heap passed in not supposed to be emptied? Here's my test program: ['' #include <boost/heap/d_ary_heap.hpp> #include <boost/heap/binomial_heap.hpp> #include <boost/heap/fibonacci_heap.hpp> #include <boost/heap/pairing_heap.hpp> #include <boost/heap/skew_heap.hpp> #include <boost/test/minimal.hpp> template <typename Heap> void test_heap_merge_memfun() { Heap heap_1, heap_2; heap_1.push(3); heap_1.push(5); heap_1.push(1); heap_2.push(2); heap_2.push(4); heap_2.push(0); heap_1.merge(heap_2); std::cout << " heap_2"; if (!heap_2.empty()) { BOOST_CHECK(4 == heap_2.top()); heap_2.pop(); BOOST_CHECK(2 == heap_2.top()); heap_2.pop(); BOOST_CHECK(0 == heap_2.top()); heap_2.pop(); std::cout << " not"; } std::cout << " emptied." << std::endl; BOOST_CHECK(heap_2.empty()); BOOST_CHECK(5 == heap_1.top()); heap_1.pop(); BOOST_CHECK(4 == heap_1.top()); heap_1.pop(); BOOST_CHECK(3 == heap_1.top()); heap_1.pop(); BOOST_CHECK(2 == heap_1.top()); heap_1.pop(); BOOST_CHECK(1 == heap_1.top()); heap_1.pop(); BOOST_CHECK(0 == heap_1.top()); heap_1.pop(); BOOST_CHECK(heap_1.empty()); } int test_main(int argc, char** argv) { test_heap_merge_memfun< boost::heap::d_ary_heap< int , boost::heap::arity<4> , boost::heap::mutable_<true> > >(); test_heap_merge_memfun<boost::heap::binomial_heap<int> >(); test_heap_merge_memfun<boost::heap::fibonacci_heap<int> >(); test_heap_merge_memfun<boost::heap::pairing_heap<int> >(); test_heap_merge_memfun< boost::heap::skew_heap<int,boost::heap::mutable_<true> > >(); return 0; } ''] When I run this program, I see that all the other heap types empty the heap passed in. I use gcc 4.2.1 with Apple clang version 4.0 on MacOSX 10.8 Cromwell D. Enage

2 1

[parameter] BOOST_PARAMETER_CONSTRUCTOR bug
by James Hirschorn 10 Jun '13

10 Jun '13

I've already submitted a bug report, but I'm also posting it here in case anyone has more info. ------------- The following variation on the example from the boost::parameter tutorial, where the required parameter is changed to optional, fails to compile. myclass_impl is being passed an empty argument list. #include <iostream> #include <boost/parameter.hpp> BOOST_PARAMETER_NAME(name) BOOST_PARAMETER_NAME(index) struct myclass_impl { template <class ArgumentPack> myclass_impl(ArgumentPack const& args) { std::cout << "name = " << args[_name] << "; index = " << args[_index] << std::endl; } }; struct myclass : myclass_impl { BOOST_PARAMETER_CONSTRUCTOR( myclass, (myclass_impl), tag , (optional (name, *) (index, *) ) ) // no semicolon }; int main(int argc, char * argv[]) { myclass C(_name="hello", _index=0); }

3 6