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

Boost Modularization: did we get it right?
by Dave Abrahams 21 May '12

21 May '12

Hi All, As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful. Thanks! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

16 28

Re: [boost] [Boost-commit] svn:boost r78350 - in sandbox/pool: boost/pool libs/pool/test
by Steven Watanabe 21 May '12

21 May '12

AMDG On 05/06/2012 06:29 AM, svart.riddare(a)gmail.com wrote: > Author: edupuis > Date: 2012-05-06 09:29:40 EDT (Sun, 06 May 2012) > New Revision: 78350 > URL: http://svn.boost.org/trac/boost/changeset/78350 > > Log: > Added new get_size() member function for pool, static_pool and object_pool. This fixes #6865. Please reopen this and any other tickets you've closed like this. Tickets are not fixed until they're at least fixed in the trunk and preferably in release. > Added: > sandbox/pool/libs/pool/test/test_bug_6865.cpp (contents, props changed) > Text files modified: > sandbox/pool/boost/pool/object_pool.hpp | 5 +++++ > sandbox/pool/boost/pool/pool.hpp | 10 ++++++++++ > sandbox/pool/boost/pool/static_pool.hpp | 5 +++++ > 3 files changed, 20 insertions(+), 0 deletions(-) > <snip> In Christ, Steven Watanabe

2 1

boost/range/algorithm/for_each.hpp - enable_if.hpp
by Richard Crossley 20 May '12

20 May '12

There would seem to be a missing include for enable_if in /boost/range/algorithm/for_each.hpp... shows up from change 18502.

1 0

[process] working directory issue
by Bertolino, Keith D. 18 May '12

18 May '12

I'm attempting to use boost::process to launch a command line tool called "catdoc.exe." Catdoc takes one argument (the path to a word document). Catdoc will then extract the text from the doc file and output it via standard error to the command line which I've redirected into a string below. So far everything works with the below code except instead of getting the text out of "a.doc" I get an error saying "catdoc cannot find codepage 1251" these codepages are saved in a directory called "charsets" which is saved in the same place catdoc.exe. The problem, I believe, is that the working directory is not set as Catdoc works fine (and finds the codepages) when I execute it manually from the command line, outside of my C++ code. My two questions are as follows: 1. Is there a way to set the working directory (and if so, will this fix my problem)? 2. Is there a way to set a time-out on the underlying process (ie. kill the process if it becomes unresponsive)? Thanks in advance for your help! My Code: using namespace boost; process::child start_child() { string exec = "catdoc.exe"; std::vector<std::string> args; args.push_back("C:\\a.doc"); process::context ctx; ctx.stderr_behavior = process::capture_stream(); return process::launch(exec, args, ctx); } string ExtractText() { string rawtext = ""; process::child c = start_child(); process::pistream &is = c.get_stderr(); std::string line; while (std::getline(is, line)) rawtext += line; return rawtext; } v/r -Keith

2 1

Re: [boost] [Boost-commit] svn:boost r78497 - website/public_html/beta/users/history
by Steven Watanabe 18 May '12

18 May '12

AMDG On 05/17/2012 08:20 AM, garcia(a)osl.iu.edu wrote: > Author: garcia > Date: 2012-05-17 11:20:21 EDT (Thu, 17 May 2012) > New Revision: 78497 > URL: http://svn.boost.org/trac/boost/changeset/78497 > > Log: > Message for fixes to MultiArray. > > Text files modified: > website/public_html/beta/users/history/version_1_50_0.html | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > You need to edit the quickbook source in feed/history, or these changes will be lost when the html is rebuilt. > Modified: website/public_html/beta/users/history/version_1_50_0.html > ============================================================================== > --- website/public_html/beta/users/history/version_1_50_0.html (original) > +++ website/public_html/beta/users/history/version_1_50_0.html 2012-05-17 11:20:21 EDT (Thu, 17 May 2012) > @@ -73,6 +73,17 @@ > </ul> > </div> > </li> > + <li> > + <div> > + <span class="library"><a href="/libs/multi_array/index.html">MultiArray</a>:</span> <ul> > + <li> > + <div> > + Concepts bug fix and Workaround for Visual Studio 2010 (<a href="https://svn.boost.org/trac/boost/changeset/78496">Patch</a>) > + </div> > + </li> > + </ul> > + </div> > + </li> > </ul> > </div> > <div id="version_1_50_0.compilers_tested"> > In Christ, Steven Watanabe

1 0

repository
by Frédéric Bron 18 May '12

18 May '12

I would like to work on a fix for the operator traits applied to STL containers but I have changed my computer and do not remember what is the official repository. Is there an official git repository that can be used? or have we to use the svn repository? What is the address to clone (git) or checkout (svn)? Regards, Frédéric

3 3

[Trac] No notification email when adding an attachment to a ticket
by Michel Morin 17 May '12

17 May '12

It is inconvenient that no notification email is sent when adding an attachment to a ticket. Alas, it's a limitation of trac for a long time. http://trac.edgewall.org/ticket/2259 Is there any plugin to automatically send notification email when attaching a file to a ticket? If not, probably we should change the message (which is displayed when we attach a file to a ticket) to explicitly say "No notification email will be sent by attaching a file. To automatically send a notification email, please leave some comment in the ticket!" Regards, Michel

1 0

[any] Move semantic
by Klaim - Joël Lamotte 17 May '12

17 May '12

Hi, My current understanding of the new rules of 5 tells me that boost::any isn't "move aware". First, am I correct? Second, I think that adding the move constructor and move operator is trivial. Again, am I correct or is there some tricks to know before adding them? Third, I want to use boost::any in a value-semantic type. Sometime it would keep a unique_ptr. If I understand correctly move semantic and unique_ptr implementation, the current boost::any implementation don't forbid me to use unique_ptr as a value type. Am I correct? Joel Lamotte

2 1

[result_of, phoenix] Inconsistency between result_of and tr1_result_of
by Michel Morin 17 May '12

17 May '12

To support nullary-callable polymorphic function objects in C++03 `result_of`, we have to specialize `result_of` for the zero-argument case. (If we don't provide specializations, the type determined by C++03 `result_of` for zero-argument function calls is defaulted to void. See the rationale in N1454.) Library authors have implemented the specialization for `result_of` to support the zero-argument case. But, in most cases, they have not specialized `tr1_result_of`. I checked a few Boost libraries: * Boost.Phoenix and Boost.Functional/Forward Only `result_of` is specialized; `tr1_result_of` is not specialized. (* Boost.Lambda Neither `result_of` nor `tr1_result_of` is specialized. So `result_of` and `tr1_result_of` for nullary function calls always evaluate to `void`.) This results in inconsistency between `result_of` and `tr1_result_of`. For example, boost::result_of< decltype(boost::phoenix::val(3))() >::type evaluates to `int const&`. But boost::tr1_result_of< decltype(boost::phoenix::val(3))() >::type evaluates to `void`. Shouldn't we provide specializations for both `result_of` and `tr1_result_of` to make result_of and tr1_result_of equivalent? (Additional question: Should we avoid the specialization of result_of when we use decltype-based result_of?) Regards, Michel

2 2

Re: [boost] [Intrusive] Cleaning up trailing white space
by Brian Wood 17 May '12

17 May '12

From: Ion Gazta?aga <igaztanaga(a)gmail.com> > It's easy to implement, I've just erased several trailing spaces in my > local copy, but it's hard to believe it can actually improve much > compilation times or file sizes. This is probably the easiest way to improve Boost. I hope authors will add this to their list of finishing touches. I know it won't make a big difference, but still think it's worthwhile. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Boost.PropertyTree custom allocator?
by Klaim - Joël Lamotte 17 May '12

17 May '12

Hi, Is there any plan to add custom allocators to boost.property_tree ? Joel Lamotte

2 1

[fusion] Trouble using BOOST_FUSION_ADAPT_ADT with boost::fusion::operator<
by GOODHART, TAYLOR 17 May '12

17 May '12

Hi all, I'm attempting to adapt a third-party struct into a fusion sequence using BOOST_FUSION_ADAPT_ADT to get access to a nice operator<. Unfortunately compilation fails and I'm not sure if it's a bug or me using the library incorrectly. As best I can read the error message, it looks like the code is attempting to compare adt_attribute_proxy structs instead of the values represented by these. Below is some code that demonstrates the problem. Can anybody help me out? Thanks, Taylor #include <boost/fusion/adapted/adt/adapt_adt.hpp> #include <boost/fusion/adapted/struct/define_struct.hpp> #include <boost/fusion/adapted/struct/adapt_struct.hpp> #include <set> #include <string> #include <boost/fusion/sequence/comparison/less.hpp> struct test1 { std::string s; const std::string & getS() const { return s; } void setS( const std::string & s_) { s = s_; } }; BOOST_FUSION_ADAPT_ADT( test1, (const std::string &, const std::string &, obj.getS(), obj.setS(val)) ) BOOST_FUSION_DEFINE_STRUCT( , test2, (std::string, s) (int, a) ) struct test3 { std::string s; }; BOOST_FUSION_ADAPT_STRUCT( test3, (std::string, s) ) using boost::fusion::operator<; int main( int argc, char * argv[]) { //Fails /*std::set<test1> destinations1; destinations1.insert(test1());*/ std::set<test2> destinations2; destinations2.insert(test2()); std::set<test3> destinations3; destinations3.insert(test3()); return 0; }

3 7

[type_erasure] RFC: New version
by Steven Watanabe 15 May '12

15 May '12

AMDG I've just committed an updated version of my type_erasure library to the sandbox at http://svn.boost.org/svn/boost/sandbox/type_erasure. Highlights of this version: * Simplified primitive concept definitions. Now, all it takes is: template<class T = _self> struct incrementable { static void apply(T& t) { ++t; } }; * Support for associated types and same_type. This allows defining iterator concepts in a uniform way: typedef mpl::vector< forward_iterator<>, same_type<forward_iterator<>::value_type, _a>, copy_constructible<_a>, typeid_<_a> > concept; std::vector<int> vec(10); for(any<concept> first(vec.begin()), last(vec.end()); first != last; ++first) { std::cout << any_cast<int&>(*first) << std::endl; } Now, _a automatically binds to int. The core library is now feature complete. Once I finish updating the iterator concepts, I think this should be ready for a formal review. Any thoughts, comments, or criticism is greatly appreciated. In Christ, Steven Watanabe

4 7

[Intrusive] Cleaning up trailing white space
by Brian Wood 14 May '12

14 May '12

>From what I can tell a lot of Boost libraries would benefit from this, but in particular I want this for the Intrusive library. It helps to improve compile times and reduce the space needed by Boost. I used grep " $" * to help with that here. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

3 2

ice_and/or vs. mpl::and_/or_
by Nathan Ridge 14 May '12

14 May '12

Hi, Is there any difference between boost::type_traits::ice_and (ice_or) and boost::mpl::and_ (or_)? Should one be preferred over the other in the implementation of other Boost libraries? Thanks, Nate

3 3

[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