Boost logo

Boost :

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2008-07-29 04:47:18

Daryle Walker wrote:
> On Jul 28, 2008, at 4:36 AM, Markus Schöpflin wrote:
>> Now I have the following issues:
>> 1) I need to increase the maximum number of pending instantiations, it
>> seems that the default value of the compiler (64) is not enough. This
>> is also true for the acc toolset, AFAICT.
> That's the price of exhaustive testing. Have you tried setting
> CONTROL_FULL_COUNTS to 0? (That preprocessor flag is made to be
> overridable by your command-line parameters.) That'll reduce the number
> of bit-count cases to just 8 or so, but you might miss some important
> cases (like bit-count == 0).

As long as its only needed for running the regression tests, I'll just go
ahead and modify the compiler parameters in my local configuration file.

>> 2) I get a number of compile time errors along the lines of:
>> cxx: Error: integer_test.cpp, line 623: expression must have a
>> constant value
>> (exprnotconst)
>> BOOST_CHECK_EQUAL( static_cast<typename
>> ----^
>> cxx: Error: ../../../boost/integer.hpp, line 375: class
>> "boost::maximum_unsigned_integral<<error-constant>>" has no member "type"
>> (notmember)
>> detected during instantiation of class
>> "boost::uint_value_t<Value> [with Value=<error-constant>]" at line 623
>> of "integer_test.cpp"
>> typedef typename maximum_unsigned_integral<Value>::type least;
>> ---------------------------------------------------------^
>> It looks like all EDG based compilers are flagging this error, see for
>> example
> I've tried redoing how the compile-time integral constants are made.
> Try out revision 47852.

OK, it works now. All integer tests are passing for me.

>> 3) There are quite a few warning about truncation of values or sign
>> changes, where I can't tell whether they are expected or not.
> I saw those in the same URL you gave. Those tests are supposed to set
> either the highest bit or the highest mantissa and/or sign bit, roll off
> the highest bit in a shift while adding the old bit value back in, then
> confirm that the value didn't change. (If I missed the highest bit,
> then it wouldn't roll off and the value will change.) Any compiler that
> warns about bits rolling off or transitioning between the mantissa and
> sign areas will complain.

OK, so these are to be expected and can be ignored.

Thanks for your work,

Boost list run by bdawes at, gregod at, cpdaniel at, john at