Subject: Re: [boost] [integer][math]Heads up on revised gcd/lcm code
From: John Maddock (jz.maddock_at_[hidden])
Date: 2017-04-26 18:46:44
> I have tested sun 12.2 through 12.5 with stlport and running the
> integer lasts from the latest 'develop'.
Thanks for this!
> My user-config.jam entry for each version has:
> <cxxflags>-features=tmplrefstatic ;
> I get, starting from the latest:
> "../../../boost/rational.hpp", line 141: Error: The type
> "boost::STATIC_ASSERTION_FAILURE<0>" is incomplete.
> "common_factor_test.cpp", line 327: Where: While specializing
> "boost::rational<my_wrapped_integer<int, 1>>".
> "common_factor_test.cpp", line 327: Where: Specialized in
> non-template code.
> 1 Error(s) detected.
This is now fixed in develop by altering the tests
This issue is caused (and would have been equally caused before) by
simply including <boost/rational.hpp>.
The problem is that the tests use gcd<T>(arg1, arg2), but this causes
all overloads of gcd to be instantiated on T, regardless of whether they
will be selected, and the rational (or multiprecision) overloads may not
compile for some random type T. Changing to gcd(static_cast<T>(arg1),
static_cast<T>(arg2)) fixes things for now. It's probably possible to
make this work if there was a real need, but since it has never worked
before (the tests simply weren't exposing the issue) and no one has
complained it's very low priority IMO.
> "../../../boost/integer/common_factor_rt.hpp", line 110: Warning:
> Identifier expected instead of "}".
That's a bug in the header for C++98 compilers (extraneous , in enum
declaration), fixed in develop.
I'm hoping the rest of the errors are cascading off this.
> ../../../boost/cstdint.hpp", line 381: Error: uintptr_t is not defined.
> appears for each test.
I've pushed a tentative fix to Boost.Config, but it's likely that this
has never worked before either!
> I did not try 64-bit tests. Should I try with a higher -std=c++11
> level with stlport ? I have separate jam entries which test each
> version without the stlport library but with c++03 or c++11 as the
I don't believe it's possible to compile with both STLPort and C++11 or
later as these use a different ABI.
There is one remaining failure with Oracle 12.5 in C++11 mode relating
to how it handles variadic templates, I'll try to find a workaround for
Many thanks for those tests!
--- This email has been checked for viruses by AVG. http://www.avg.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk