November 2006 - Boost - lists.preview.boost.org

[mpl] gcc ICE in aux_/has_tag<>
by Eric Niebler 11 Nov '06

11 Nov '06

Any chance one of the MPL gurus could have a look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29653 and see if any possible changes to mpl/aux_/has_tag<> could make gcc happy? Preprocessed source code is attached to the bug report. FWIW, this is against Boost HEAD. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

"time" in global namespace?
by Matthias Schabel 11 Nov '06

11 Nov '06

While fine-tuning my units code, I've run into something that's puzzling to me. Here's a minimal example: if I try to compile this program: #include <iostream> namespace boost { namespace units { typedef int time; typedef double length; } // namespace units } // namespace boost int main(void) { using namespace boost::units; length x = 10; time t = 2; return 0; } I get an error : "'time' not declared in this scope". However, if I fully qualify the namespace for "time", it compiles fine: #include <iostream> namespace boost { namespace units { typedef int time; typedef double length; } // namespace units } // namespace boost int main(void) { using namespace boost::units; length x = 10; boost::units::time t = 2; return 0; } This is on Xcode 2.4 (gcc 4.0.1). I assume that there is a definition of "time" somewhere in the standard headers that is polluting the global namespace. Has anyone run into this before? Any suggestions? Matthias

3 3

Compile-time assert
by Johan Paulsson 11 Nov '06

11 Nov '06

Below is the compile-time assert I use. Would it be a useful addition to Boost? I know Boost has compile-time assertions, but I think this is different: ----------- template<bool if_> struct assertion { enum { assert }; }; template<> struct assertion<false> {}; template<int if_, int assert_ = assertion<if_ != 0>::assert> struct assert {}; template<typename if_, int assert_ = if_::assert> struct type_assert {}; // they are used via typedef: typedef assert<false> assert_1; typedef type_assert<assertion<false> > assert_2; // type_assert can make nicer error messages: template<typename type_> struct not_integer_type : assertion< std::numeric_limits<type_>::is_integer > {}; typedef type_assert<not_integer_type<float> > assert_3; -------------- Because assertion<false>::assert does not exist, the default template argument to assert is bad when if_ == 0. The "assert_1" and "assert_2" typedefs should make the compiler say something similar to: file.cpp line 123: error: 'assert' is not a member of 'assertion<false>' The "assert_3" typedef should make the compiler say something similar to: file.cpp line 123: error: 'assert' is not a member of 'not_integer_type<float>' It works on the compilers I have: - CodeWarrior 10.0 - GCC 3.2, 3.3, 3.4, 4.0, 4.1 - Intel C++ 9.0 - Visual C++ 7.1, 8.0 Regards, Johan Paulsson

3 9

[proprocessor] PP challenge!
by Eric Niebler 11 Nov '06

11 Nov '06

I have a preprocessing task that exceeds my limited abilities. If any PP gurus want to step in and prevent me from hurting myself further, I would be very grateful. My problem is this: I want to mpl::and_ together a bunch of predicates. mpl::and_ has a limit of 4 arguments. So this is wrong: mpl::and_< pred1, pred2, pred3, pred4, pred5 > but this is ok: mpl::and_< pred1, pred2, pred3, mpl::and_< pred4, pred5 > > The challenge, should you choose to accept it, is to write some PP magic that, given a MAKE_PREDICATE(z, n, data) macro and a max arity (which is greater than 4!), generates a properly nested mpl::and_-ing of the predicates. Any takers? -- Eric Niebler Boost Consulting www.boost-consulting.com

6 15

Re: [boost] [1.34.0] Boost.Build
by Boris Gubenko 11 Nov '06

11 Nov '06

Robert Ramey wrote: > hp acc - has recently started to pass when a user sent > me a patch to the test header. The current failures suggest > something amiss with the testing environment. It looks like some intermittent I/O problem: the compiler could not open STL include files. A test would pass, the next would fail with "cannot open source file..." error and so on. It all happened during serialization library tests run, some 450 tests. By the time this library tests were complete, the problem went away. I restarted the tests, we'll see tomorrow. In any case, as Robert Ramey stated, this is an environmental problem. Boris

1 0

Boost regression notification (2006-10-24 [RC_1_34_0])
by Douglas Gregor 11 Nov '06

11 Nov '06

Boost Regression test failures Report time: 2006-10-24T10:41:49Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 48 failures in 9 libraries iostreams (10) lambda (1) mpl (5) parameter (3) program_options (7) random (1) serialization (16) spirit (4) utility (1) |iostreams| bzip2_test: msvc-7.1 msvc-8.0 example_test: vc-6_5-stlport file_descriptor_test: cw-9.4 finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 mapped_file_test: cw-9.4 zlib_test: msvc-7.1 msvc-8.0 |lambda| exception_test: gcc-3_4_4_tru64 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 |parameter| python_test: qcc-3.3.5_gpp sfinae: borland-5_8_2 vc-6_5-stlport |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: cw-9.4 variable_map_test_dll: cw-9.4 winmain_dll: cw-9.4 |random| random_test: intel-linux-9.0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_non_default_ctor2_text_archive: qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |spirit| action_tests: qcc-3.3.5_cpp qcc-3.3.5_gpp action_tests_debug: qcc-3.3.5_cpp qcc-3.3.5_gpp |utility| operators_test: gcc-3.4.5_linux_x86_64

3 2

[mpl] annoying trivial bug in boost/mpl/print.hpp
by Ian McCulloch 10 Nov '06

10 Nov '06

Hi, In boost 1.33.1, using MPL with gcc -pedantic gives an annoying error, boost/mpl/print.hpp:62: error: comma at end of enumerator list The trivial fix is to remove the comma at the end of line 60 of that file, which I did for my downloaded copy of boost ages ago, then promptly forgot about it. But I just checked the CVS and it seems that this bug is still present in both HEAD and RC_1_34_0. It would be great if this could be fixed before 1.34. Cheers, Ian McCulloch

2 2

rational.hpp VC 7.1, 8.0 compilation failures
by Ralf W. Grosse-Kunstleve 10 Nov '06

10 Nov '06

With the latest boost CVS, both VC 7.1 and VC 8.0 fail to compile #include <boost/rational.hpp> The error is shown below. The problem is due to "unsigned long long" being the same as "unsigned __int64", which makes this code in boost/math/common_factor_rt.hpp fail: #ifdef BOOST_HAS_LONG_LONG BOOST_PRIVATE_GCD_UF( unsigned long long ); #endif #ifdef BOOST_HAS_MS_INT64 BOOST_PRIVATE_GCD_UF( unsigned __int64 ); #endif As a quick workaround I tried: #ifdef BOOST_HAS_LONG_LONG # if !defined(_MSC_VER) BOOST_PRIVATE_GCD_UF( unsigned long long ); # endif #endif And a similar patch a few lines down (complete diff is below). This fixes the problem. I am sure this is not the final answer, but I'm uncertain which combinations of #if defined(...) is acceptable. Advice is highly appreciated. Thanks! Cheers, Ralf This is with VC 8.0: C:\home\rwgk\dist\build80>cl /DBOOST_DISABLE_THREADS /DNDEBUG /Ox /GR /EHsc /nologo /D_SECURE_SCL=0 /D_CRT_SECURE_NO_DEPRECATE /wd4996 /Zm800 /IC:\home\rwgk\dis t\boost /c include_rational.cpp include_rational.cpp C:\home\rwgk\dist\boost\boost/math/common_factor_rt.hpp(302) : error C2766: explicit specialization; 'boost::math::detail::gcd_optimal_evaluator<unsigned __int64>' has already been defined C:\home\rwgk\dist\boost\boost/math/common_factor_rt.hpp(298) : see previous definition of 'gcd_optimal_evaluator<unsigned __int64>' C:\home\rwgk\dist\boost\boost/math/common_factor_rt.hpp(326) : error C2766: explicit specialization; 'boost::math::detail::gcd_optimal_evaluator<__int64>' has already been defined C:\home\rwgk\dist\boost\boost/math/common_factor_rt.hpp(322) : see previous definition of 'gcd_optimal_evaluator<__int64>' Index: common_factor_rt.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/math/common_factor_rt.hpp,v retrieving revision 1.2 diff -u -r1.2 common_factor_rt.hpp --- common_factor_rt.hpp 5 Nov 2006 07:10:42 -0000 1.2 +++ common_factor_rt.hpp 8 Nov 2006 06:36:01 -0000 @@ -295,7 +295,9 @@ BOOST_PRIVATE_GCD_UF( unsigned long ); #ifdef BOOST_HAS_LONG_LONG +# if !defined(_MSC_VER) BOOST_PRIVATE_GCD_UF( unsigned long long ); +# endif #endif #ifdef BOOST_HAS_MS_INT64 @@ -319,7 +321,9 @@ BOOST_PRIVATE_GCD_SF( char, unsigned char ); // should work even if unsigned #ifdef BOOST_HAS_LONG_LONG +# if !defined(_MSC_VER) BOOST_PRIVATE_GCD_SF( long long, unsigned long long ); +# endif #endif #ifdef BOOST_HAS_MS_INT64

2 1

[function_types]
by Steven Watanabe 10 Nov '06

10 Nov '06

AMDG A few more typos in the documentation "is_member_function_pointer<F,tag<const_qualified,default_cc>::value" is missing closing > in about_tag_types.html "Is it save to have the synthesis templates take a callable builtin type or an MPL sequence as the first template argument?" should say "Is it safe..." in fseq.html, rationale.html In Christ, Steven Watanabe

2 1

What's happenning to the regression results?
by Arkadiy Vertleyb 10 Nov '06

10 Nov '06

Hi all, What is the reason of this sudden increase in the number of failures for a lot of libraries? Has something underlying been broken? Was some platforms status changed from "broken" to "not broken", etc. Or is it just that a lot of new failures have been introduced? Thanks, Arkadiy

4 3