Just a few hours ago, the following question came up: Variable cannot appear in a constant-expression
Luckily for the OP, the answer provided did solve his problem, but I cannot reproduce the solution.
I've attempted to simplify the code even more and I am now stuck with the following:
#include <bitset>
int main ()
{
const size_t length_1 = static_cast<const size_t>(1.0f);
std::bitset<length_1> bits_1;
const size_t length_2 = static_cast<const size_t>(1.0f / 1.0f);
std::bitset<length_2> bits_2;
}
If compiled with -pedantic, the first example is accepted by the compiler, but the one with a division (but obviously same number) is rejected with the message "length_2 cannot appear in a constant-expression".
Without -pedantic as well as with -pedantic -std=c++0x it's accepted without any further warning.
This is the full output of g++ -v (I apologize for german, but I'm sure you get the right information anyway):
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Ziel: i686-linux-gnu
Konfiguriert mit: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread-Modell: posix
gcc-Version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
What's the reason for this behaviour? I guess it's 1.0f beeing recognized as some special constant and therefore changing the behaviour of static_cast?
The answer is in §5.19.
C++03 allows only arithmetic constant expressions which meet the requirements for an integral constant expression: "Floating literals (2.13.3) can appear only if they are cast to integral or enumeration types."
So while it seems reasonable to treat 1.0f/1.0f as 1 it's nevertheless beyond the standard. To avoid "floating point arithmetic of the target machine" sounds like a good explanation to me. GCC 4.7 requires libgmp, libmpfr, and libmpc to make this work.
C++11 imposes no such restrictions. But the accuracy is still implementation defined. Implementations are only "encouraged" to provide consistent results for compile-time and run-time evaluation.