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

Re: [boost] Code question on fusion tag_of.hpp
by Dave Steffen 10 Aug '12

10 Aug '12

Mathias Gaunard wrote: > On 08/08/2012 23:39, Dave Steffen wrote: > > Hi Folks > > > > During a recent bug hunt, we came across the following (Boost 1.49, > > fusion/adapted/std_tuple/tag_of.hpp): > > > > #include <tuple> > > > > namespace std > > { > > template <typename... Elements> > > class tuple; > > } > > > > We find this rather puzzling -- why is this here? As far as we can > > tell, this doesn't do anything. > > It forward declares std::tuple so that it can specialize its traits > for it. > > But it really shouldn't do that, since there is no guarantee this > declaration is compatible with the standard one. Well, first of all, it's not a forward declaration, right? std::tuple is declared in whatever gets included with #include<tuple>, right? So it's not a forward declaration, it's a... what? A backwards declaration? :-) It's redundant at any rate. (Or I'm completely wrong, in which case I'm missing something.) And then, yes, this may or may not be compatible with the real std::tuple (which is what we were looking in to when we found this). -- Dave Steffen Software Engineer NUMERICA CORPORATION www.numerica.us (970) 461-2000 main (970) 612-2327 direct

3 3

boost 1.50.0 - function_input_iterator issue
by hans ewetz 09 Aug '12

09 Aug '12

In boost v1.50.0 the function_input_iterator constructor performs dereferencing which may prevent creation of an 'end' iterator. Should it not instead dereference in the dereference() function and possibly keep a dirty flag indicating if the current value is valid? Apologies if I have missed any similar posting related to this problem. Hans

2 1

[review] Multiprecision review results
by Jeffrey Lee Hellrung, Jr. 09 Aug '12

09 Aug '12

Summary -------- John Maddock and Christopher Kormanyos' Multiprecision library is ACCEPTED for inclusion into Boost, with 8 YES votes, 1 NO vote, and 1 CONDITIONAL vote. Details -------- Most reviewers noted that this was a sufficiently good first step toward extended precision arithmetic for inclusion into Boost. I think John and Chris will agree that there remains quite a bit of work left to do, but as one reviewer noted, John has an excellent track record regarding Boost development and Chris has been extremely dedicated during the pre-review development, review process, and post-review development, so I think this bodes well for the library's future. I'm going to highlight what I perceive to be some of the bigger issues raised by various individuals involved with in discussion, but I will share all my notes via Google Docs [1], and of course even further details are available in the mailing list archive. I note that many of the issues raised during the review have already been addressed by John and Chris. Mixed-Type Arithmetic -------- This has come up over and over again, especially in the context of allowing extended precision types within the same "family" to interoperate, which I think is tractable. Removing my review manager hat for a moment, perhaps a tag dispatching system similar to Boost.MPL or Boost.Fusion could be used, where all arithmetic types within the same family have the same tag, and hence only allow mixing types with the same tag. Most types will have a unique tag (which, I don't know, could default precisely to the arithmetic type?), but, e.g., Vicente's family of fixed-precision (and maybe even fixed-point) types would all be identifiable as being in the same family, and a traits class would determine the result types of the various arithmetic operations. Mixed-type arithmetic outside the above scope seems more tricky, but some users seem to still desire this in some form. Actual desired use cases will undoubtedly help here. Naming -------- Several commented on the redundancy of "mp_" prefix for identifiers already residing the boost::mp namespace. Narrowing Conversions -------- cpp_dec_float should round rather than truncate on narrowing conversions. Review manager hat off: I wonder if a radix-2 implementation of an arbitrary precision float should ultimately be prioritized and recommended over the present radix-10 implementation? It sounds like conversions in general should be reviewed, but I'm entirely sure myself where they all stand. If possible, narrowing conversions should be explicit while others (that would guarantee no loss of precision) may be implicit. This would be a departure from C++ builtin types. Performance -------- Phil, the lone NO vote, lamented that the scope of the library was evidently beyond simple fixed-precision (e.g., 128-bit or 256-bit) integral types, which is his desired use case. Indeed, at least in an earlier version of MP, expression templates seemed to give a performance penalty relative to using the raw back-end types; in theory, expression templates should give no performance hit, but compilers just may not be there yet. In any case, several reviewers requested that the scope of the library be clarified up front in the documentation. Regularization/Normalization of Back-End Behavior via Front-End -------- As Edward pointed out, different back-ends generally have different behavior on some "exceptional" cases, making use of the corresponding front-ends in generic contexts at times cumbersome (specifically when the generic context needs to handle said exceptional cases). A couple examples given were division-by-zero and conversion from a string with invalid characters. It is by no means *necessary* to regularize/normalize *all* such differences, but as many as possible and practical should be identified, considered, and documented. Separation of Data Structures and Algorithms -------- Though requested, John and Steven have maintained that this simply isn't very practical. I've gathered that there are too many special cases that (1) would make implementations a nightmare; and (2) would have be addressed very carefully (i.e., in a likely not-very-readable way) to avoid any performance hits. Since this has come up a few times, maybe something could be said in the documentation about this. Thanks to everyone who submitted reviews and participated in the discussion. Let me know if I left out anything you feel is particularly significant or inaccurate. - Jeff [1] https://docs.google.com/document/d/19YgtWBQt0lpjJoJDOtAlScZAZyOwzbHimiYTi-g…

7 6

Code question on fusion tag_of.hpp
by Dave Steffen 09 Aug '12

09 Aug '12

Hi Folks During a recent bug hunt, we came across the following (Boost 1.49, fusion/adapted/std_tuple/tag_of.hpp): #include <tuple> namespace std { template <typename... Elements> class tuple; } We find this rather puzzling -- why is this here? As far as we can tell, this doesn't do anything. (Well, it did participate in a long, ugly compiler error about variadic templates, which is why we found it.) What are we missing? Thanks for any insight. -- Dave Steffen Software Engineer NUMERICA CORPORATION www.numerica.us (970) 461-2000 main (970) 612-2327 direct

2 1

Re: [boost] [review] Multiprecision and uBlas
by John Maddock 09 Aug '12

09 Aug '12

>> Also running the tests for UBLAS with mp_number put in place of >> floats/doubles would be interesting. > > I've added modified versions of uBlas tests 1-7 to the multiprecision lib, > most of the tests pass, but there are two outstanding issues: > > * Test1: I had to disable a couple of tests because they trigger debug > assertons inside the STL. I get the same errors when testing with type > double, so I conclude it's a uBlas issue, not sure why they aren't > triggered in the regular regression tests though... > * Test3: I can't get this to compile, and the error are so inscrutable I > don't know what the issue is, I'd need some help from a uBlas expert to > figure those out. Hold on that was a mistake, test1 does pass, tests 3 and 7 don't compile for reasons I don't understand. I'd need some help from a uBlas expert to figure those out. John.

2 1

[Algorithm] [Range] `is_sorted` is duplicate
by Michel Morin 08 Aug '12

08 Aug '12

Both Boost.Algorithm and Boost.Range have `is_sorted` function. Would it be better to deprecate Boost.Range's `is_sorted`? Also, Both Boost.Algorithm and Boost.Range have `iota` function. (In this case, Boost.Algorithm's `iota` returns void, but Boost.Range's `iota` returns the range.) Regards, Michel

1 0

[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