- Boost - lists.boost.org

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

[MPL?] Borland broken big time
by Nicola Musatti 10 Nov '06

10 Nov '06

Hallo, some change committed to the 1.34 branch around November 7 caused havoc for the Borland compilers, both 5.6.4 and 5.8.2, compare Doug's regression notifications from Nov. 6 and Nov. 7. What happened? Note that many regressions start with the following: boost/mpl/aux_/preprocessed/bcc/arg.hpp 26: Not an allowed type Cheers, Nicola Musatti

2 1

Re: [boost] [1.34.0] Boost.Build
by Matt Doyle 10 Nov '06

10 Nov '06

> [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera > Matt Doyle wrote: > >> [mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Witt > <snip> > I.e. BB is independent of the Boost releases. > > > If it has to go > > away, and I'm not saying for a moment that it shouldn't, v1 > should at > > least be formally deprecated for one release cycle so as > not to catch > > the users off guard. > > BBv1 has been in deprecation status for more than 8 months > now (I don't > really remember that far back, so it may be even longer). And it will > still be deprecated after the 1.34.0 release. It just won't > be included > with the release. If any one want to use it, it will still be > available > in CVS. The *big* caveats are that it is no longer supported > (inside nor > outside of Boost). And Boost libraries will no longer use it. I know, it's been deprecated for some time now, I was referring in terms of releases. A user who is not involved with the developers list is not going to know what has transpired between releases and may get a surprise when they upgrade. 1.33 distributed, 1.34 distributed & deprecated, 1.35 gone (but available for DL) Makes more sense, to me at least <shrug> > > So in a sense this is more like MFC, if you must insist on using > Microsoft references ;-) Sorry, I didn't realize my wording came off like it did until I saw it in the reply. MS analogies don't belong here ;/ > > Scanned by McAfee GroupShield {X3BTB534}

1 0