From: Hartmut K. <har...@gm...> - 2009-03-22 22:44:44
|
> > Ok, should be really fixed this time. I tried compiling with Boost > 1.37, > > 1.38 and trunk. > > We're getting there! :) It works here (I'm testing if Karma tests > "int_numerics" + "real_numerics" and Qi test "real" compile) with > older Boost versions (tested with 1.37 and 1.38). > > However it doesn't work with trunk: > .../support/detail/sign.hpp: In function > 'T boost::spirit::detail::changesign(T) [with T = float]': > .../qi/numeric/detail/real_impl.hpp:83: > instantiated from here > .../support/detail/sign.hpp:57: error: no type named 'bits' > in 'struct boost::math::detail::fp_traits_native<float>' > .../support/detail/sign.hpp:58: error: 'get_bits' is not a > member of 'boost::math::detail::fp_traits_native<float>' > > Interesting: by looking at Boost.Math fp_traits, I see that it > dispatches to fp_traits_native in my case (I'm with gcc-4.1 and its > standard STL on Linux), and there is no bits-related stuff in it -- it > is only in fp_traits_non_native. > I would guess your configuration is different, so that in your case > fp_traits dispatches to fp_traits_non_native? By forcing that behavior > (with -DBOOST_MATH_DISABLE_STD_FPCLASSIFY), indeed, it works for me > too. Ok that explains why it worked for me and not for you. Thanks for investigating. I committed a change which I believe should do the trick. > Side note: Karma tests give this error in > karma/detail/output_iterator.hpp: > .../output_iterator.hpp:113: error: > dependent-name 'std::basic_string<T>::const_iterator' > is parsed as a non-type, but instantiation yields a type > .../output_iterator.hpp:113: note: say > 'typename std::basic_string<T>::const_iterator' if a type is > meant > > I added "typename" in r1134, but it was removed in r1136, was that > intentional? Ooops, that got lost underway while resolving a merge conflict (and VC is not always enforcing typenames, so it stayed unnoticed). I re-added the typename again. Thanks! Regards Hartmut |