dynamic_bitset.hpp fails to compile with g++ (Ubuntu 4.3.3-5ubuntu2) 4.3.3

[solusstutlus@…]

source/boost/dynamic_bitset/dynamic_bitset.hpp: In member function ‘size_t boost::dynamic_bitset<Block, Allocator>::count() const’: source/boost/dynamic_bitset/dynamic_bitset.hpp:1021: error: ‘mode’ cannot appear in a constant-expression source/boost/dynamic_bitset/dynamic_bitset.hpp:1021: error: template argument 1 is invalid source/boost/dynamic_bitset/dynamic_bitset.hpp:1021: error: expected `>' before ‘*’ token source/boost/dynamic_bitset/dynamic_bitset.hpp:1021: error: expected `(' before ‘*’ token source/boost/dynamic_bitset/dynamic_bitset.hpp:1021: error: expected primary-expression before ‘>’ token

Seems like this update to gcc does not like const values passed as parameters to templates...

[Zara <zaravalle@…>]

The part that is not identified as constant is 'no_padding', participant in 'mode'. The other part, 'enough_table_width' is correctly identified as const.

[Zara <zaravalle@…>]

Solution (apparently) found: The current file documents something introduced for GCC 3.4:

NOTE: Explicitly qualifying "bits_per_block" to workaround regressions of gcc 3.4.x const bool no_padding =

dynamic_bitset<Block, Allocator>::bits_per_block

CHAR_BIT * sizeof(Block);

Removing the explicit qualification compiles with GCC 4.3. To be tested: does the compiled object work OK?

const bool no_padding = bits_per_block == CHAR_BIT * sizeof(Block);

HTH

[zaravalle@…]

Suggested patch that fixes this ticket

[zaravalle@…]

Attached file seems to correct this problem. Explicit qualification of bits_per_block breaks compilation undef gccx 4.3, so the patch just detects this specific compiler and version (and later versions, also), and does not make the explicit qualification in such case.

Works OK with gcc 4.1 (Centos 5.x) and gcc 4.3 (ubuntu 9.04)

[zaravalle@…]

I have reopened it as I accidentally closed it, but the proposed fix is still valid, from my point of view.

[Daniel James]

Hi, I was just looking at this, as I promised I would. But it seems that someone beat me to it and didn't say anything. Changes in trunk: [52879], [52880], [52881].

[zaravalle@…]

Thanks to all. I have now learned something else about versions and patch levels, by loking at the definitive solution. I suppose now is the right time to close the ticket!