May 2012 - Boost - lists.preview.boost.org

[config] 4 new C++11 macros added
by John Maddock 14 May '12

14 May '12

A long time back I was asked for a bunch of new config macros which have finally now been added: BOOST_NO_CXX11_ALLOCATOR The standard library does not provide a C++11 version of `std::allocator` in <memory>. BOOST_NO_CXX11_ATOMIC_SP The standard library <memory> does not support atomic smart pointer operations. BOOST_NO_CXX11_HDR_FUNCTIONAL The standard library does not provide a C++11 compatible version of <functional>. BOOST_NO_CXX11_SMART_PTR The standard library header <memory> has no shared_ptr and unique_ptr. Enjoy, John.

6 11

[ICL] #6853: boost::icl::contains(NaN) returns true
by Andrew Hundt 13 May '12

13 May '12

I had submitted a bug report for icl, and the response I included below seemed indicate this is more for the list than a bug report. It deals with an issue where boost::icl::contains(NaN) returns true, where any NaN value cannot actually be contained within an interval, and so should return false. I'm dealing with data that comes from a physical device, so each measurement the system returns is not guaranteed to be valid. We set those invalid measurements to NaN. However, when the data is valid it falls into certain intervals that I found icl well suited for, despite not falling into the original use case of time scheduling I find it to be a reasonable representation to work with. While IEEE floating point numbers is not required by the C++ standard, it is a standard that does seem to have fairly wide use in C++. It seems, at least in my use case, that NaN is a very reasonable value to use and fits well with the functionality icl provides. However, I wanted to open this to wider opinions to learn about the state of the issue. Cheers! Andrew Hundt ---------- Forwarded message ---------- From: Boost C++ Libraries <noreply(a)lists.boost.org> Date: Fri, May 4, 2012 at 6:50 AM Subject: Re: [Boost C++ Libraries] #6853: [ICL] boost::icl::contains(NaN) returns true To: Cc: boost-bugs(a)lists.boost.org #6853: [ICL] boost::icl::contains(NaN) returns true -----------------------------------------------+---------------------------- Reporter: Andrew Hundt <ATHundt@…> | Owner: jofaber Type: Bugs | Status: closed Milestone: To Be Determined | Component: ICL Version: Boost 1.49.0 | Severity: Problem Resolution: invalid | Keywords: icl -----------------------------------------------+---------------------------- Changes (by jofaber): * status: new => closed * resolution: => invalid Comment: Hi Andrew, icl code is not intended to be NaN complete. NaN is a weird animal that breaks concepts the icl is based on. Completing icl for NaN would make the code unnecessarily clumsy for cases that are hardly ever used. If you desire to complete your code for NaN cases you will have to do it in your code or write your own NaN layer around the icl. Regards, Joachim -- Ticket URL: <https://svn.boost.org/trac/boost/ticket/6853#comment:1> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.

7 15

[complex] Feedback and Potential Review Manager
by Christopher Kormanyos 13 May '12

13 May '12

Hi Matthieu, I would like to provide a detailed feedback on the proposed Boost.Complex. I am terribly sorry about the late response on this, as I was not doing well in winter when this topic was more active. First of all, great work with this, Matthieu. I believe the community desperately requires this facility. Boost.Complex appears to have two main goals: A) Provide acceleration for pure imaginary numbers. B) Allow complex to be used with user-defined types. For goal B), I have briefly tested parts of the Boost.Complex code with the cpp_dec_float multiprecision data type proposed for Boost.Multiprecision by John Maddock. My Tests include: * Test some elementary transcendental functions. * Test the overall package via computation of orthogonal polynomials.* My test file (complex.cpp) is included in this e-mail. * Visual Studio 2010, SP1. * Proposed Boost.Multiprecision and boost trunk. Remarks: 1) Various functions use macros like M_PI_2. These macros do not provide enough precision for a multiprecision type. And they will be inefficient for some fixed-point types. Perhaps you need to "bite the bullet" and use boost::math::constants. (Is M_PI_2 even part of C++, or is it only lurking around in <math.h> of GCC?) 2) Ditto for the LN_10 and LN_2 constants. Does boost::math::constants support ln_ten()? I do know that it has ln_two(). 3) I disagree with explicit complex(const T& re = T(0.), const T& im = T(0.)) I believe this constructor should be non-explicit. See ISO/IEC 14882:2011, Section 26.4.2. 4) I would really like to see global operators for seamless interaction of complex<T> with integer PODs. The proposed code of boost::complex forces explicit construction from integer "all the way" to boost::complex<T> just to, for example, multiply with 2. This is extremely costly as most multiprecision or fixed-point types have specially optimized routines for multiplication with integer PODs. Perhaps something like this would be good template<typename T> complex<T> operator*(const complex<T>& z, int n) { T re(z.real()); T im(z.imag()); re *= n; im *= n; return complex<T>(re, im); } 5) In the exp() function, polar() can not be resolved without explicit template parameter. Instead of this: template<typename T> inline complex<T> exp(const complex<T>& x) { return polar(exp(x.real()), x.imag()); } I needed this: template<typename T> inline complex<T> exp(const complex<T>& x) { return polar<T>(exp(x.real()), x.imag()); } I don't know who's right here, your code or the compiler. 6) The tanh() function and some other functions compute the exponent twice. By that I mean both exp(x) as well as exp(-x). I believe that division would be faster if exp(-x) were computed with (1 / exp(x)). Or is there an issue with branch cuts that mandates the potentially redundant calculation? 7) I hope to find time to test this code further with a tiny fixed-point class. But I might be too busy for that extra work. REVIEW PROGRESS: I may potentially be qualified for review manager. I do know the math and the code. I am also well-versed with all aspects of software review, assessment and audit situations. BUTTT!!! I'm not as good at C++ as some of you folks and I'm a real beginner at boost. Nonetheless, If nobody better steps forward, I could potentially manage the review of Boost.Complex. Best regards, Chris.

8 33

Latest changes to scoped enum emulation break existing code
by Hartmut Kaiser 13 May '12

13 May '12

Hey all, The latest commit to the scoped enumerator emulation breaks existing code using the previous version of this functionality. Please see the Spirit regression tests for examples. Revision: 78407 Author: anthonyw Date: Thursday, May 10, 2012 12:06:15 PM Message: Combine scoped enum emulation from thread library into detail/scoped_enum_emulation.hpp ---- Modified : /trunk/boost/detail/scoped_enum_emulation.hpp Modified : /trunk/boost/thread/cv_status.hpp Deleted : /trunk/boost/thread/detail/scoped_enum.hpp Modified : /trunk/boost/thread/future.hpp Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

4 9

[context] - Mac OS X fix
by Daniel Larimer 13 May '12

13 May '12

It seems that while I was off using an old (but stable) version of Boost.Context Oliver has gone and rewritten it (again) and it has been approved (awesome)! I decided I should migrate my code to the latest API but it appears that no one tested it on OS X. I had to update the fcontext_x86_64_sysv_macho_gas.S: 1) @PLT is an ELF concept that generates the error: junk `@PLT' after expression 2) I had to add an '_' before align_stack otherwise things didn't link. + call _align_stack /* align stack */ - call align_stack@PLT /* align stack */ - call _exit@PLT /* exit application */ + call _exit /* exit application */ With that fix, you can add OS X x64 to your tested platforms. What version of boost will include Context? Dan

2 1

[newbie] running tests
by Nathan Ridge 13 May '12

13 May '12

Hi, I have a (probably silly) question about running Boost tests. Where can I find a summary of the results after running the tests? For example, I ran the Boost.Fusion tests by going to libs/fusion/test and running ../../../bjam. Here's the last few lines of the output: common.mkdir ../../../bin.v2/libs/fusion/test/invoke_procedure.test common.mkdir ../../../bin.v2/libs/fusion/test/invoke_procedure.test/gcc-4.8.0 common.mkdir ../../../bin.v2/libs/fusion/test/invoke_procedure.test/gcc-4.8.0/debug common.mkdir ../../../bin.v2/libs/fusion/test/invoke_procedure.test/gcc-4.8.0/debug/functional gcc.compile.c++ ../../../bin.v2/libs/fusion/test/invoke_procedure.test/gcc-4.8.0/debug/functional/invoke_procedure.o gcc.link ../../../bin.v2/libs/fusion/test/invoke_procedure.test/gcc-4.8.0/debug/invoke_procedure testing.capture-output ../../../bin.v2/libs/fusion/test/invoke_procedure.test/gcc-4.8.0/debug/invoke_procedure.run **passed** ../../../bin.v2/libs/fusion/test/invoke_procedure.test/gcc-4.8.0/debug/invoke_procedure.test common.mkdir ../../../bin.v2/libs/fusion/test/swap.test common.mkdir ../../../bin.v2/libs/fusion/test/swap.test/gcc-4.8.0 common.mkdir ../../../bin.v2/libs/fusion/test/swap.test/gcc-4.8.0/debug common.mkdir ../../../bin.v2/libs/fusion/test/swap.test/gcc-4.8.0/debug/sequence gcc.compile.c++ ../../../bin.v2/libs/fusion/test/swap.test/gcc-4.8.0/debug/sequence/swap.o gcc.link ../../../bin.v2/libs/fusion/test/swap.test/gcc-4.8.0/debug/swap testing.capture-output ../../../bin.v2/libs/fusion/test/swap.test/gcc-4.8.0/debug/swap.run **passed** ../../../bin.v2/libs/fusion/test/swap.test/gcc-4.8.0/debug/swap.test ...updated 1098 targets... I can tell from this that the last two tests passed, but what about the other 1096 that scrolled off the screen? Should there not be a summary somewhere? Thanks, Nate

2 1

[quickbook] incorrect image path for note, warning, etc
by lcaminiti 12 May '12

12 May '12

Hello all, When generating Quickbook docs on a single HTML page `bjam onehtml` the images for notes, warning, etc do not appear because they have the incorrect path: onehtml path (incorrect) images/note.png normal path (correct) ../../../../../doc/src/images/warning.png How do I fix this? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-quickbook-incorrect-image-path-for… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[general] Preventing compiler ABI clashes
by Vicente J. Botet Escriba 12 May '12

12 May '12

Hi, After some exchanges with Anthony, I have recently reread http://www.boost.org/development/separate_compilation.html#abi and I suspect that I'm not the single one that misunderstood the context of this protocol. As noted in "Counter Argument #2: Prefix/suffix headers have a tendency to "spread" to other boost libraries - for example if boost::shared_ptr<> forms part of your class's ABI, then including prefix/suffix headers in your code will be of no use unless shared_ptr.hpp also uses them. Authors of header-only boost libraries may not be so keen on this solution - with some justification - since they don't face the same problem. " even header-only libraries should use this protocol if other not-header only libraries must conform to it. Shouldn't every Boost library use this protocol? Or at least, allows the user to enable it? What about adding an attribute (ABI Clash Protected) to the library documentation stating if a library supports this protocol? Is there a way to check if a library supports this protocol completely? Best, Vicente

1 0

[hash] Turn on BOOST_HASH_NO_IMPLICIT_CASTS by default
by Daniel James 12 May '12

12 May '12

Hello everyone, There have been occasional issues where Boost.Hash will incorrectly hash an object that doesn't have a hash function but is convertible to bool. I added an extra templated overload of hash_value which contains a static assert. The idea is that it's a better match than the implicit cast, so it will cause a compile error in this case. This is currently only activated when a macro is defined, as it could break otherwise valid code. I was a bit worried about making any interface changes because at this stage, Boost.Hash should be very stable from release to release. The problem turned up again yesterday, so I'm starting to think it's enough of a problem that it's worth activating this be default. A different solution might be to change the implement of Boost.Hash for bools, so that the bool overload isn't required. But that would be treating the sympton, as other implicit casts could cause problems. An example of valid code that will now break is something like: struct base; std::size_t hash_value(base const&); struct derived : base { void some_method_but_no_extra_state(); }; boost::hash<derived> derived_hash; Currently that will automatically use base's hash_value, with this change it will be a compile error. Although that might be a good thing, as sometime it is an error to use the base's hash function. Of course, there will be a macro to keep the old behaviour. Any objections to this change?

3 5

Re: [boost] [Review Request] Multiprecision Arithmetic Library
by Christopher Kormanyos 11 May '12

11 May '12

Sorry, John my file was too big and admin rejected post. The candidate file is now 7-zip and should make it through. <snip> >> I experimented with FFTs. We need your inputs if we *really* >> want to make very high-precision available at this stage. <snip> >> maybe about 30 lines of code. > Nice, had no idea it could be implemented in such a small space! Ooops, my bad. It was 100 lines. I guess I was in a daze by then. <snip> > So my gut feeling is to hold off for now, and maybe do things > properly later (dynamic allocation, better std lib support etc)? I agree. We should pull the reigns on it for now. We won't get the reliability we need if we try to do something fast. I could go on indefinitely with big-numbs, but we have to get that first version potentially reviewed. I should really get back to my book project soon. But I'm definitely in on any relevant review issues. > I think the existing ones work out quite nicely now thanks, > I could use some ideas for integer and maybe rational number examples, > but that's a whole other ball game ;-) I'm not an integer guy. Maybe someone could help us out here. But what springs to my mind is: * Prime factorization * Greatest common denominator (GCD) * Primality testing for Mersenne Primes (has an exceptionally simple algo) * MD5, SHA-1, 2, etc. (but cool std::uint32_t reference apps already exist)<snip> >> I resolved the excessive guard digit issue and reduced the guard digits >> to the necessary amount (and provide rationale in a code comment). <snip> > Sure, or mail me a patch and I'll run the full tests > (or you can - just cd into libs/multiprecision/test and > do a "bjam --enable-specfun" and then wait for a long time!) > Thanks, John. OK. I attached my proposed version in /big_number/multiprecision/cpp_dec_float.hpp. The diffs include the removal of some non-needed constants, the trimming of max_digits10 and a minor improvement to the multiplication. Thanks, Chris.

4 29