- Boost - lists.boost.org

[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

[config] New NO_COPYABLE, DELETE_COPY_CTOR and DELETE_COPY_ASSIGN macros
by Vicente J. Botet Escriba 11 May '12

11 May '12

Hi, I'm using the following BOOST_NO_COPYABLE, BOOST_DELETE_COPY_CTOR, BOOST_DELETE_COPY_ASSIGN and macros in Boost.Thread (see http://svn.boost.org/svn/boost/trunk/boost/thread/detail/delete.hpp) I guess some of you have their own similar macros. For uniformity purposes, couldn't them be added to Boost.Config/ Boost Helper Macros <cid:part1.09000208.02050709@wanadoo.fr> if I provide a patch with doc and tests? Best, Vicente [section:delete `=delete` emulation] C++11 allows to delete some implicitly generated functions as constructors and assignment using '= delete' as in public: CLASS(CLASS const&) = delete; CLASS& operator=(CLASS const&) = delete; On compilers not supporting this feature, we can relays on a partial simulation, by declaring the function as private without definition. private: CLASS(CLASS &); CLASS& operator=(CLASS&); The emulation is good but partial as the private functions are still visible. To have the best the user should write public: #ifndef BOOST_NO_DELETED_FUNCTIONS CLASS(CLASS const&) = delete; CLASS& operator=(CLASS const&) = delete; #else // BOOST_NO_DELETED_FUNCTIONS private: CLASS(CLASS&); CLASS& operator=(CLASS&); public: #endif // BOOST_NO_DELETED_FUNCTIONS The following macros allows to take in account the features the compiler provides and have the same effect public: BOOST_DELETE_COPY_CTOR(CLASS) BOOST_DELETE_COPY_ASSIGN(CLASS) As these come together quite often when we want to make a non copyable class the user can use instead public: BOOST_NO_COPYABLE(CLASS) [section:delete_copy_ctor `BOOST_DELETE_COPY_CTOR(CLASS)`] This macro deletes the copy constructor when the compiler supports it or makes it private. It can be included on the public section only. [endsect] [section:delete_copy_assign `BOOST_DELETE_COPY_ASSIGN(CLASS)`] This macro deletes the copy assignment when the compiler supports it or makes it private. It can be included on the public section only. [endsect] [section:no_copyable `BOOST_NO_COPYABLE(CLASS)`] This macro makes a class as no copyable, disabling copy construction and assignment. It can be included on the public section only. [endsect] [endsect]

3 3

[build]
by Emil Dotchevski 11 May '12

11 May '12

Hello, I get the following Boost Build error and I have no idea what's wrong. Halp! C:\Users\Zajo\z\git\reverge\bjam\test c:/Users/Zajo/z/git/munch/boost-build/build\feature.jam:138: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "boost.locale.iconv" : "on" "off" : "optional" "propagated" c:\Users\Zajo\z\git\lib\boost_1_49_0\libs\locale\build\Jamfile.v2:19: in modules.load from module Jamfile</c:/Users/Zajo/z/git/lib/boost_1_49_0/libs/locale/build> c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:314: in load-jamfile from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:62: in project.load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:766: in project.use from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:89: in load-used-projects from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:73: in project.load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:766: in project.use from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:89: in load-used-projects from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:73: in project.load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:766: in project.use from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:89: in load-used-projects from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:73: in load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:115: in load-parent from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:464: in initialize from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:309: in load-jamfile from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:62: in load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:115: in load-parent from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:464: in initialize from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:309: in load-jamfile from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:62: in load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:168: in project.find from module project c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:369: in find-really from module object(project-target)@683 c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:435: in object(project-target)(a)683.find from module object(project-target)@683 c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:816: in resolve-reference from module targets c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:833: in targets.generate-from-reference from module targets c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:1217: in generate-dependencies from module object(typed-target)@1905 c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:1268: in object(typed-target)(a)1905.generate from module object(typed-target)@1905 c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:732: in generate-really from module object(main-target)@2599 c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:704: in object(main-target)(a)2599.generate from module object(main-target)@2599 c:/Users/Zajo/z/git/munch/boost-build\build-system.jam:736: in load from module build-system c:\Users\Zajo\z\git\munch\NT\..\..\munch\boost-build\kernel\modules.jam:283: in import from module modules c:\Users\Zajo\z\git\munch\NT\..\..\munch\boost-build\kernel\bootstrap.jam:142: in boost-build from module c:\Users\Zajo\z\git\munch\NT\..\..\munch\boost-build.jam:6: in module scope from module Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 2