- Boost - lists.boost.org

[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