Re: beast-0.7.4 issues with g++-4.5

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Sat, Apr 09, 2011 at 09:09:23PM +0200, Stefan Westerfeld wrote:
> It seems that beast-0.7.4 doesn't build with g++-4.5; I am mostly using ubuntu
> for development work, so I didn't investigate what causes the problem yet, but
> on Debian/unstable, I get:
> 
> CXX    birnetutils.lo
> birnetutils.cc:253:111: error: array bound is not an integer constant before ']' token
> birnetutils.cc:254:111: error: array bound is not an integer constant before ']' token
> birnetutils.cc:255:109: error: array bound is not an integer constant before ']' token

I investigated the issue a little further. First of all, I tried using BOOST_STATIC_ASSERT
instead of BIRNET_STATIC_ASSERT, just to see if our static assertion facility needs to
be fixed. However, BOOST_STATIC_ASSERT behaves the same way like BIRNET_STATIC_ASSERT:
it fails on those expressions involving DBL_MIN/DBL_MAX/DBL_EPSILON on g++-4.5, and
succeeds with g++-4.4. There are IMHO several ways to fix compilation with g++-4.5.

1) Fix g++-4.5.x: I reported a bug to the gcc BTS, but the gcc maintainers seem
to think that expressions involving floating point math are not valid integer
constants:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48681

2) Move assertions to configure check: as the assertions are meant to prevent
compilations unless the assertions succeed, the closest we could do would be to
move the assertions involving floating point constraints to a configure check,
and disallow building if the check fails.

3) Move assertions to test suite: we could also make a unit test which checks
these constraints. You could compile BEAST, but the test suite (make check)
would break unless the assertions succeed.

4) Move assertions to runtime checks at startup. For instance with global
constructors, we could keep the test in the same file, but the constructor
would do the assertions and prevent starting BEAST if the test does not work.

5) We could disable these static assertions altogether (or conditionally for
g++ >= 4.5.0) , but I think thats not such a good option, as they were designed
to prevent problems down the road, so I'm not considering this at the moment.

As there are multiple approaches on how to fix the issue, I'd like some
guidance here as on which approach to take. I can make a patch/merge request
for approach 2, 3 or 4, as soon as the decision on which route to take is made.

   Cu... Stefan
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan