- Boost - lists.boost.org

[context] doesn't build on 32-bit osx
by Luke Elliott 08 Aug '12

08 Aug '12

Hello Oliver There's actually already a ticket on this (https://svn.boost.org/trac/boost/ticket/7110 not from me) but since it's unassigned I thought I'd post here with a few more details. bjam address-model=32 -d+2 Performing configuration checks - x86 : yes Jamfile</Users/macpro/dev/checkouts/boost-trunk/libs/context/build>.gas ../../../bin.v2/libs/context/build/darwin-4.2.1/debug/address-model-32/architecture-x86/asm/fcontext_i386_sysv_macho_gas.o as -o "../../../bin.v2/libs/context/build/darwin-4.2.1/debug/address-model-32/architecture-x86/asm/fcontext_i386_sysv_macho_gas.o" "../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S" ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:82:suffix or operands invalid for `push' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:83:suffix or operands invalid for `push' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:84:suffix or operands invalid for `push' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:86:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:87:Missing operand value assumed absolute 0. ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:87:junk `[.-1b]' after expression ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:90:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:91:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:92:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:101:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:112:suffix or operands invalid for `pop' ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:113:Missing operand value assumed absolute 0. ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:113:junk `[.-3b]' after expression ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:116:suffix or operands invalid for `push' darwin.compile.c++ ../../../bin.v2/libs/context/build/darwin-4.2.1/debug/address-model-32/fcontext.o Applying the 64-bit change from Daniel Larimer on 13th May and adding -arch=i386 to the as flags gets things further: as -o "../../../bin.v2/libs/context/build/darwin-4.2.1/debug/address-model-32/architecture-x86/asm/fcontext_i386_sysv_macho_gas.o" "../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S" -arch i386 ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:87:Missing operand value assumed absolute 0. ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:87:junk `[.-1b]' after expression ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:113:Missing operand value assumed absolute 0. ../../../libs/context/src/asm/fcontext_i386_sysv_macho_gas.S:113:junk `[.-3b]' after expression From a quick google, it sounds like _GLOBAL_OFFSET_TABLE is an ELF only thing. I'm now way out of my depth and probably can't really help any further (though happy to try out any fixes). Probably not of much relevance but: sw_vers ProductName: Mac OS X ProductVersion: 10.7.4 BuildVersion: 11E53 as -version Apple Inc version cctools-822, GNU assembler version 1.38 I hope that is of some use! ucontext throws up a deprecated warning so it would be nice to switch to boost.context one day. I've not tried Mountain Lion yet so don't know if they've actually removed ucontext support or if it's still deprecated. Best regards Luke Elliott.

2 3

[1.51][Wave] Last minute commit
by Hartmut Kaiser 07 Aug '12

07 Aug '12

Hey, I would like to ask for permission to commit rev 79783 to the release branch (see attached patch). This fixes a bug introduced only recently and will fix the current regressions (see here: http://tinyurl.com/c44ql68, for instance). The patch is for Wave only and does not touch any of the other Boost libraries. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 4

[review] Multiprecision review (June 8th - 17th, 2012)
by Jeffrey Lee Hellrung, Jr. 07 Aug '12

07 Aug '12

Okay, it's that time. Apologies for not sending a reminder, but there had been a lot of pre-review comments over the last week or so, so I think this has been on at least some people's radar. The original review announcement is given below. On Tue, May 29, 2012 at 2:08 PM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung(a)gmail.com> wrote: > Hi all, > > The review of the proposed Boost.Multiprecision library authored by John > Maddock and Christopher Kormanyos has been scheduled for > > June 8th - June 17th, 2012 > > and will be managed by myself. > > From the Introduction: > > -------- > "The Multiprecision Library provides *User-defined* integer, rational and > floating-point C++ types which try to emulate as closely as practicable the > C++ built-in types, but provide for more range and precision. Depending > upon the number type, precision may be arbitrarily large (limited only by > available memory), fixed at compile time values, for example 50 decimal > digits, or a variable controlled at run-time by member functions. The types > are expression-template-enabled for better performance than naive > user-defined types." > -------- > > And from the original formal review request from John: > > -------- > Features: > > * Expression template enabled front end. > * Support for Integer, Rational and Floating Point types. > > Supported Integer backends: > > * GMP. > * Libtommath. > * cpp_int. > > cpp_int is an all C++ Boost licensed backend, supports both arbitrary > precision types (with Allocator support), and signed and unsigned fixed > precision types (with no memory allocation). > > There are also some integer specific functions - for Miller Rabin testing, > bit fiddling, random numbers. Plus interoperability with Boost.Rational > (though that loses the expression template frontend). > > Supported Rational Backends: > > * GMP > * libtommath > * cpp_int (as above) > > Supported Floating point backends: > > * GMP > * MPFR > * cpp_dec_float > > cpp_dec_float is an all C++ Boost licensed type, adapted from Christopher > Kormanyos' e_float code (published in TOMS last year). > > All the floating point types, have full std lib support (cos sin exp, pow > etc), as well as full interoperability with Boost.Math. > > There's nothing in principal to prevent extension to complex numbers and > interval arithmetic types (plus any other number types I've forgotten!), > but I've run out of energy for now ;-) > > Code is in the sandbox under /big_number/. > > Docs can be viewed online here: > http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… > -------- > Any review discussion should take place on the developers' list ( boost(a)lists.boost.org) and anyone may submit a formal review, either publicly to the entire list or privately to just myself. As usual, please consider the following questions in your formal review: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And, most importantly, please explicitly answer the following question: Do you think the library should be accepted as a Boost library? Lastly, please consider that John and Christopher have compiled a TODO list [1] based on pre-review comments. Feel free to comment on the priority and necessity of such TODO items, and whether any might be show-stoppers or warrant conditional acceptance of the library. Thanks in advance; looking forward to the discussion! - Jeff (& John & Christopher) [1] http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h…

16 67

[type_erasure] Review started (July 18-27, 2012)
by Lorenzo Caminiti 06 Aug '12

06 Aug '12

Hello all, *** The review of Steven Watanabe's proposed Boost.TypeErasure library begins on July 18, 2012 and ends on July 27, 2012. *** THE LIBRARY C++ provides runtime polymorphism through virtual functions. They are a very useful feature, but they do have some limitations. * They are intrusive. In generic programming, we can design an interface which allows third-party types to be adapted to it. * They require dynamic memory management. Of course, most of the problems can be avoided by using an appropriate smart pointer type. Even so, it still acts like a pointer rather than a value. * Virtual functions' ability to apply multiple independent concepts to a single object is limited. The Boost.TypeErasure library solves these problems allowing us to mirror static generic programming at runtime. Library source: http://svn.boost.org/svn/boost/sandbox/type_erasure/ Pre-built documentation: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ You can also download archives with pre-built documentation from: http://sourceforge.net/projects/steven-watanabe.u/files/ YOUR REVIEW Please submit a review to the mailing-list by replying to this email ("[boost] [type_erasure] Review ..." should be in the subject). Please state clearly whether you think this library should be accepted as a Boost library. Other questions you may want to consider: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? Thanks in advance to all who participate in the review discussion -- I'm looking forward to it! The review manager. --Lorenzo

12 56

interest in generic cyclic visitor?
by Jan Herrmann 06 Aug '12

06 Aug '12

Hello, I have an implementation of generic cyclic visitor. It is available at https://github.com/janherrmann/visitor . With my implementation it is possible to create non-member, non-friend templates which behave like virtual functions. Additionally it can be used as a base for multimethod implementation. Moreover it can be used to build a extensible type information system. All test cases compile with msvc-10.0 and gcc-mingw-4.6.2. Is there need for such a library? Jan Herrmann

3 5

[multiprecision] Some Performance gains
by John Maddock 05 Aug '12

05 Aug '12

Following the review of the multiprecision lib, I've been experimenting with some of the issues raised, currently focusing on performance improvements. Anyhow, I now have some results for improved *front end* performance, I haven't tried to seriously optimize the cpp_int backend yet (which was one of the criticisms), but for more on that see below. So... by way of measuring front end performance - the "abstraction penalty" if you like I've used a special backend type "arithmetic_backend<A>" where A can be any builtin arithmetic type. For tests I've used Boost.Math's special function test data for floating point types, and Phil Endecott's Delaunay code for integer performance. Win32 VC10 first: Delaunay test: int64_t : 9.45241 mp_number<arithmetic_backend<int64_t>, false> : 9.66815 Bessel Functions Test: Time for Bessel Functions - double = 0.015859 seconds Time for Bessel Functions - arithmetic_backend<double> - no expression templates = 0.0225565 seconds Time for Bessel Functions - arithmetic_backend<double> = 0.0376449 seconds Non Central T: Time for Non-central T - double = 0.456739 seconds Time for Non-central T - arithmetic_backend<double> - no expression templates = 0.459957 seconds Time for Non-central T - arithmetic_backend<double> = 1.08256 seconds Ubutunu Linux x64, GCC-4.6.1: Delaunay Test: int64_t 2.3969 mp_number<arithmetic_backend<int64_t>, false> 2.38334 Bessel Functions Test: Time for Bessel Functions - double = 0.0224617 seconds Time for Bessel Functions - arithmetic_backend<double> - no expression templates = 0.020384 seconds Time for Bessel Functions - arithmetic_backend<double> = 0.0220476 seconds Non central T: Time for Non-central T - double = 0.622985 seconds Time for Non-central T - arithmetic_backend<double> - no expression templates = 0.554527 seconds Time for Non-central T - arithmetic_backend<double> = 0.800129 seconds So to all intents and purposes there's now no abstraction penalty at all, except when using expression templates (which should be reserved for heavyweight backends anyway). Notice how the mp_number code is sometimes slightly faster, and sometimes slightly slower than the native type - I've observed that completely trivial changes to the test/measuring code can change this around - I suspect, but can't prove that the abstraction layer changes the decisions made by the compiler's optimizer resulting in somewhat capricious differences between results. With regard to the cpp_int backend, I still have work to do, however things do actually look pretty good on Linux x64 for the Delaunay test: Running calculations for: int64_t, int128_t (this is Phil's 128-bit special-case code) Number of flips = 23892000 Total execution time = 3.28337 Running calculations for: int64_t, mp_int128_t Number of flips = 23892000 Total execution time = 3.05434 Running calculations for: int64_t, mp_int128_t (ET) Number of flips = 23892000 Time per calculation = 3.02904e-08 Running calculations for: int64_t, cpp_int Number of flips = 23892000 Total execution time = 5.41737 On Win32, I'm still a touch behind Phil's code, however, I haven't written a dedicated NxN->2N multiplication routine (yet): Running calculations for: int64_t, int128_t Number of flips = 23892000 Total execution time = 14.2189 Running calculations for: int64_t, mp_int128_t Number of flips = 23892000 Total execution time = 24.5114 Running calculations for: int64_t, mp_int128_t (ET) Number of flips = 23892000 Total execution time = 19.741 Running calculations for: int64_t, cpp_int Number of flips = 23892000 Total execution time = 33.5 All the new code is in the sandbox, but I haven't documented any of the changes yet... Regards, John.

3 4

[typeof][implementation]why not use decltype or conditional expr?
by Larry Evans 05 Aug '12

05 Aug '12

Why couldn't the BOOST_TYPEOF macro be defined to simply use the new keyword, decltype, if it's available? I assume the macro, BOOST_HAS_DECLTYPE, indicates whether it is available. And if decltype not available, why couldn't it use the conditional expression method described here: http://www.artima.com/cppsource/foreach2.html I would think that would be simpler and more portable. -regards Larry

5 6

Formal review request: TypeIndex library
by Antony Polukhin 05 Aug '12

05 Aug '12

Hi, I'd like to ask to add Boost.TypeIndex to review queue. Introduction TypeIndex is an extended C++11 type_index library, that * works with disabled RTTI * can store const-volatile-reference info about types (if user requested it) * has all the functionality of std::type_index * has portable across compilers and platforms functionality for getting demangled type names * works across modules/shared libraries * does not require C++11 to work Docs: http://apolukhin.github.com/type_index/index.html Git: https://github.com/apolukhin/type_index Sources (zipped): https://github.com/apolukhin/type_index/zipball/master Git contains `patched` folder with TypeIndex'ed (and untested) versions of some existing boost libraries (Boost.Any, Boost.Graph, Boost.Math, Boost.MSM, Boost.PropertyMap, Boost.PropertyTree). Those libraries now do not require RTTI to compile. More libraries could be added to this list. Previous threads (checking interest): * Is there interest in typeid(TYPE).name() like function that does not require RTTI http://lists.boost.org/Archives/boost/2012/05/193491.php * [boost] Is there interest in copyable type_info that does not require RTTI (was: Is there interest in typeid(TYPE).name() like function that does not require RTTI) http://lists.boost.org/Archives/boost/2012/05/193519.php * [boost] [type_index] C++03 implementation in boost? http://lists.boost.org/Archives/boost/2012/07/194627.php P.S.: Additional thanks to Agustín K-ballo Bergé for pointing out and fixing some bugs. P.P.S.: It would be great to schedule review to the end of September. -- Best regards, Antony Polukhin

2 3

[1.51.0] Beta1 release available; release branch open for bug fixes and doc fixes
by Marshall Clow 05 Aug '12

05 Aug '12

The beta releases are available at: http://boost.cowic.de/rc/ They are identical to the rc2 releases. The files (and associated md5s) are: e3a51b82894a67ac438eaa08192929eb *boost_1_51_0_beta1.tar.gz 1c541236f98dcaa706e7f8eabb11ebfc *boost_1_51_0_beta1.tar.bz2 964f150ce9d7bcaba74255aba73d338a *boost_1_51_0_beta1.zip e23467c3369a53189300c76e8c848aa1 *boost_1_51_0_beta1.7z The final release is scheduled for Monday, August 20th. The release candidate is scheduled to to be built Thursday, August 16th. That gives us less than two weeks to apply post-beta bug fixes and doc updates. Until August 13th permission is not required to merge bug fixes and documentation updates. Starting August 13th permission of a release manager is required for all merges. As always, New libraries and new features are not allowed during a post-beta period. Thanks, -- The Release Managers

2 1

[type_erasure] Review ended
by Lorenzo Caminiti 04 Aug '12

04 Aug '12

Hello all, The review of Boost.TypeErasure ended on Aug 3, 2012. Stay tuned for my decision on the library. Thank you very much to Steven, everyone that submitted a review, and everyone that participated in the discussions. The review manager, --Lorenzo On Fri, Aug 3, 2012 at 11:00 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > Hello all, > > *** The review of Boost.TypeErasure ends today Aug 3, 2012. If you are > planning to submit a review, please do so by the end of today. *** > > Thank you to all that have participated to the review so far. > > The review manager, > --Lorenzo > > On Jul 27, 2012 1:41 PM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >> >> Hello all, >> >> After consulting the review wizards and Steven, I am extending >> Boost.TypeErasure review of one week, until August 3, 2012. >> >> Thank you to all that have submitted a review already and I am looking >> forward to receiving additional submissions. >> >> The review manager, >> --Lorenzo >> >> On Jul 27, 2012 3:22 AM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>> >>> Hello all, >>> >>> On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> >>> wrote: >>> > On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti >>> > <lorcaminiti(a)gmail.com> wrote: >>> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >>> >> begins on July 18, 2012 and ends on July 27, 2012. *** >>> > >>> > *** Boost.TypeErasure review ends in 5 days. Please submit your reviews >>> > :D *** >>> >>> *** Boost.TypeErasure review ends today July 27, 2012. If you are >>> planning to submit a review, please do so as soon as possible. *** >>> >>> Thank you to everyone who has commented on the library and submitted a >>> review so far! >>> >>> The review manager, >>> --Lorenzo >>> P.S. I am considering extending the review until end of day Sunday >>> July 29, 2012... I will keep you posted. >>> >>> > There have been interesting discussions on the library on the ML but I >>> > have not received any official review yet :( Especially if you are a >>> > user of Boost Any, Function, and Any Iterator, you definitely want to >>> > take a look at Type Erasure as it generalizes solutions provided by >>> > those other libraries. >>> > >>> > Thank you. >>> > >>> > The review manager. >>> > --Lorenzo >>> > >>> >> THE LIBRARY >>> >> >>> >> C++ provides runtime polymorphism through virtual functions. They are >>> >> a very useful feature, but they do have some limitations. >>> >> * They are intrusive. In generic programming, we can design an >>> >> interface which allows third-party types to be adapted to it. >>> >> * They require dynamic memory management. Of course, most of the >>> >> problems can be avoided by using an appropriate smart pointer type. >>> >> Even so, it still acts like a pointer rather than a value. >>> >> * Virtual functions' ability to apply multiple independent concepts to >>> >> a single object is limited. >>> >> The Boost.TypeErasure library solves these problems allowing us to >>> >> mirror static generic programming at runtime. >>> >> >>> >> Library source: >>> >> http://svn.boost.org/svn/boost/sandbox/type_erasure/ >>> >> >>> >> Pre-built documentation: >>> >> >>> >> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ >>> >> >>> >> You can also download archives with pre-built documentation from: >>> >> http://sourceforge.net/projects/steven-watanabe.u/files/ >>> >> >>> >> YOUR REVIEW >>> >> >>> >> Please submit a review to the mailing-list by replying to this email >>> >> ("[boost] [type_erasure] Review ..." should be in the subject). >>> >> >>> >> Please state clearly whether you think this library should be accepted >>> >> as a Boost library. >>> >> >>> >> Other questions you may want to consider: >>> >> 1. What is your evaluation of the design? >>> >> 2. What is your evaluation of the implementation? >>> >> 3. What is your evaluation of the documentation? >>> >> 4. What is your evaluation of the potential usefulness of the library? >>> >> 5. Did you try to use the library? With what compiler? Did you have >>> >> any problems? >>> >> 6. How much effort did you put into your evaluation? A glance? A >>> >> quick reading? In-depth study? >>> >> 7. Are you knowledgeable about the problem domain? >>> >> >>> >> Thanks in advance to all who participate in the review discussion -- >>> >> I'm looking forward to it!

1 0