- Boost - lists.boost.org

[1.46.1] branches/release open for bug fixes only
by Beman Dawes 03 Mar '11

03 Mar '11

We are going to do a point release next week. branches/release is now open for merging bug fixes only, including documentation fixes. As always, please make sure the fix is stable on trunk before merging to release. The cutoff for merging is noon Eastern US time on Tuesday, March 8th. We have to hold to a tight schedule because of other commitments later in the month. --Beman

6 6

New meta-multiprecision library of interest.
by Topher Cooper 03 Mar '11

03 Mar '11

The following will be of interest to the numericists among us: Christopher Kormanyos. 2011. Algorithm 910: A Portable C++ Multiple-Precision System for Special-Function Calculations. ACM Trans. Math. Softw. 37, 4, Article 45 (February 2011), 27 pages. DOI=10.1145/1916461.1916469 http://doi.acm.org/10.1145/1916461.1916469 The abstract: This article presents a portable C++ system for multiple precision calculations of special functions called e_float. It has an extendable architecture with a uniform C++ layer which can be used with any suitably prepared MP type. The system implements many high-precision special functions and extends some of these to very large parameter ranges. It supports calculations with 30 ... 300 decimal digits of precision. Interoperabilities with Microsoft’s® CLR, Python, and Mathematica® are supported. The e_float system and its usage are described in detail. Implementation notes, testing results, and performance measurements are provided. I only just saw this, and skimmed the article but, based on that skimming (and subject to possible misunderstandings) it is worth noting: A key part of the package not fully captured in the abstract is that it provides a uniform C++ interface for MP packages. For the purposes of that uniform interface its special functions includes a pretty good set of not-so-special functions like addition, integer part, etc. It includes its own MP package designed for portability. There are a lot of functions (inevitably) not covered. I noticed the total absence of specifically statistical distribution functions -- not even the error function seems to be included. The author claims to welcome others to extend the package, however. The Python interoperability is provided via Boost.Python so the author has some awareness of Boost. To me this library seems very Boostish, some Booster deeper in the numerical library field might wish to investigate how hard it would be to Boostify this and whether the author is interested. The ACM, which holds the copyright on this paper, allows copies to be made for "personal use." I think that sharing a copy with anyone with a reasonably serious non-comercial interest who doesn't otherwise have access falls within this permission, so if you need a copy of the paper let me know via my first name on my net domain at company topherc. Topher

1 0

[xint] Review
by Christian Henning 03 Mar '11

03 Mar '11

Hi there, first I like to congratulate Chad for his very valuable contribution to the boost community. > 3. Please explicitly state in your review whether the library should be accepted. YES! > > 4. The general review checklist is provided below: > > - What is your evaluation of the design? Looks very thought out to me. No complains. > - What is your evaluation of the implementation? I find the code pretty hard to read. Is it true that the code is cut to 80 characters a line? I'm not sure if that's a good decision. There are plenty of warnings when warning level is set to 4 on VS2010. Most of them are "warning C4127: conditional expression is constant" which seems to me that they could be removed by using compile time polymorphism. > - What is your evaluation of the documentation? Looks very nice. Just one thing. Where can I find a list of preprocessor symbols that are used during the compilation process. For instance, I like to know more about BOOST_XINT_MOVE. The rsa example is missing the "iterator" header. > - What is your evaluation of the potential usefulness of the library? If someone needs a bigint lib he/she should look no further. Would be interesting to see how well this lib compares to similar C libs in terms of performance and functionality. > - Did you try to use the library? With what compiler? Did you have any > problems? I used it with VS2010 in 64bit configuration. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? A glance with some example code testing. > - Are you knowledgeable about the problem domain? Not really. Regards, Christian

3 4

[1.46.1] Should we try for a point release?
by Beman Dawes 03 Mar '11

03 Mar '11

>From my viewpoint, the process of putting together a release is now smooth enough that I'm willing to do a point release, but... (1) Do we have enough fixes that will be ready by, say, a week from today to make a point release worthwhile? (2) We would need to be sure that we have a procedure that ensures that fixes for the point release don't get dropped from the next full release. (3) The C++ committee meets March 21-26 in Madrid. That means there's about three weeks, say March 14 - April 3, where those of us, including me, going to that meeting will be too tied up for Boost work. That why (1) says "a week from today". --Beman

6 9

Re: [boost] [xint] Boost.XInt formal review
by Jarrad Waterloo 03 Mar '11

03 Mar '11

This library is useful as is but I would suggest a few additional features for convenience especially among the most common use cases. 1) convenience functions preferably, documented example is acceptable, for extracting a integer, int, long int ... starting at a particular unsigned bit offset for a particular length 2) convenience functions preferably, documented example is acceptable, for creating a mask starting at a particular unsigned bit offset for a particular length 3) examples of using this if possible with boost::date in order to efficient work with dates outside the existing limits 4) conversion to and from dynamic_bitset [already suggested just seconding] 5) conversion to and from bitset For all those other reviewers who may complain about performance when comparing with GMP, please bear in mind that large numbers are useful to domains other than security were assembly level performance is nice but doesn't outweigh other concerns such as portability and ease of use. This library and others much needed even overdue for the C++ non C community.

2 1

Phoenix 3 Review
by Joel Falcou 03 Mar '11

03 Mar '11

So here is my short review on phoenix 3. I wont comment on the quality of the code and the implementation as I followed Thomas durign his GSoC. On an user perspective, i'll place myself on the "advacned user" plate. i see Phoenix as a great to enable lazy evalaution in a large number of situation. its integration in proto is now making it a nice boilerplate code for more advanced libraries. I've played with test adn examples and found them to be good. My overall opinion is that YES, this version of Phoenix fulfills the requirements of th eprevious review adn thomas addressed them in quite an efficient way. Now, as an advanced nitpicker ;) i have a small set of request: - the doc need more examples of proto interoperability either in use cases or in various extension points. IIRC there was sone phoenix-> C cod ein a string example that was never finished, it coudl be good if this could be fleshed out. multistage programming is a Nice technique that need promotion and exposure. Phoenix seems to be perfect for that. - Could the various compile time / runtime performances tests be itnegrated in the doc if they are a/ done and b/ give some insight. If needed i can run some on non-trivial architecture/compiler and report results So, I very welcome the addition of Phoenix 3 as a full citizen of boost.

3 2

1.46 problems
by Nikolay Mladenov 03 Mar '11

03 Mar '11

I am resending this since I accidentally sent an unfinished email. I recently upgraded from 1.43 to 1.46 and this broke our serialization. We could not read archives saved with 1.43. I the investigation I noticed the following issues. 1. in basic_binary_iarchive tracking_type is loaded as integer type or bool, but in basic_binary_oarchive it is stored as primitive type tracking_type. This breaks custom binary archives that have overloads for integer types and bool. this problem probably applies to other internal serialization types (collection_size_type, version_type, etc), but I have not investigated this. 2. We use custom binary archives which have overloads for integer types (loosely) like that: class custom_binary_iarchive : boost::archive::binary_iarchive_impl<custom_binary_iarchive> { public: void load(integral_type &t){...} void load(non_integral_type &t){...} }; When loading std::vector from archive stored with 1.43 the following execution paths occur: std::vector <T> v; custom_binary_iarchive ar(..); ar >> v; .... //goes in load_collection(Archive& ar, Container &s) collection_size_type count; ar>>BOOST_SERIALIZATION_NVP(count); .... //and finally reaches custom_binary_iarchive::load(non_integral_type &t); if instead I use polymorphic archive based on the custom_binary_iarchive I get: std::vector <T> v; polymorphic_iarchive_route<custom_binary_iarchive> ar(..); ar >> v; .... //in load_collection(Archive& ar, Container &s) collection_size_type count; ar>>BOOST_SERIALIZATION_NVP(count); ...... //goes into polymorphic_iarchive_impl::load_override(nvp<collection_size_type> &t) ..... //goes into polymorphic_iarchive_route::load(boost::ulong_long_t &t) //since collection_size_type has conversion to unsigned long long ... //and finally reaches custom_binary_iarchive::load(integral_type &t) The bottom line is that collection_size_type deserializes differently with polymorphic and regular archives. I am now trying to fix the problems by introducing overloads for all the serialization library's internal types, but it seems to me that some of those problems are actually bugs. Please advise on the best way to tackle this issues. Another question I have, and excuse me if this has been discussed (but I could not find it), is when should a custom archive overload save/load and when save_override/load_override? Thanks in advance, Nikolay Mladenov Sitius Automation Inc

1 0

[serialization] 1.46 problems
by Nikolay Mladenov 03 Mar '11

03 Mar '11

I recently upgraded from 1.43 to 1.46 and this broke the serialization. We could not read archives save with 1.43. I the investigation i noticed the following issues. 1. in basic_binary_iarchive tracking_type is loaded as integer type or bool, but in basic_binary_oarchive it is stored as primitive type tracking_type. This breaks custom binary archives that have overloads for integer types and bools to be broken this problem probably applies to other internal serialization types (collection_size_type, version_type, etc), but I have not investigated this. 2. I have a custom binary archives which have overloads for integer types (loosely) like: class custom_binary_iarchive : boost::archive::binary_iarchive_impl<custom_binary_iarchive> { };

1 0

[log] Current status
by Gregory Symons 02 Mar '11

02 Mar '11

Hi, I've been looking at Boost.Log, and I was wondering what it's current status is? It was provisionally accepted almost a year ago; any ideas when it will make it into a boost release? -- Gregory Symons <gsymons(a)drillinginfo.com> Developer DrillingInfo <http://www.drillinginfo.com>

3 3

differences between sandbox and 1.46.0
by Frédéric Bron 02 Mar '11

02 Mar '11

I am working in the sandbox on an addition to the type trait library. I have run a diff between boost/type_traits directory in version 1.46.0 and in the sandbox. To my surprise, many files which I did not change myself are different: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… So my questions are: - is the sandbox supposed to be up to date compared to the trunk? - if not, there is a risk that people spend time working with wrong code; can we think of a procedure to update the sandbox when new versions are issued? Frédéric

3 2