October 2006 - Boost - lists.boost.org

Boost regression notification (2006-10-17 [RC_1_34_0])
by Douglas Gregor 17 Oct '06

17 Oct '06

Boost Regression test failures Report time: 2006-10-17T10:31:47Z 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… 58 failures in 12 libraries filesystem (2) io (1) iostreams (7) mpl (6) parameter (6) program_options (2) random (1) rational (5) serialization (18) spirit (7) test (2) utility (1) |filesystem| mbcopy: sun-5.8 wide_test: sun-5.8 |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 example_test: vc-6_5-stlport gzip_test: msvc-7.1 msvc-8.0 zlib_test: msvc-7.1 msvc-8.0 |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 vector_c: sun-5.8 |parameter| optional_deduced_sfinae: sun-5.8 preprocessor_deduced: sun-5.8 python_test: qcc-3.3.5_gpp sun-5.8 sfinae: borland-5_8_2 vc-6_5-stlport |program_options| unicode_test_dll: borland-5_8_2 variable_map_test_dll: borland-5_8_2 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 sun-5.8 vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_contained_class_binary_archive_dll: gcc-3.2.3_linux test_contained_class_xml_archive: gcc-3.2.3_linux 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 mix_and_match_trees: sun-5.8 typeof_iterator: intel-vc8-win-9.1 msvc-8.0 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

[interprocess] Segment existance check
by Ryan, Paul L. 17 Oct '06

17 Oct '06

Ion, I don't know if I'm just missing it or if this feature doesn't exist, but is there a feature in interprocess to check that a segment exists prior to attempting to find or construct a variable in that segment? If it doesn't exist this would be an extremely useful feature so that when an application goes to create an object in shared memory where the shared memory segment has not been created the program doesn't just segfault but gives the application at least a small chance of exiting gracefully (i.e. a thrown exception). As always thanks for your attention, Paul Ryan SAIC - Tactical Systems

2 1

Naming of 32/64 bit libs
by awk＠imm.dtu.dk 17 Oct '06

17 Oct '06

Hi, I need both the 32 and 64 bit versions of the boost dll's to coexist in the same directory. Currently when I compile boost, both versions get the same names, e.g. boost_date_time-vc80-mt-1_33_1.dll. Is there any way (apart from modifying boost-base.jam) to change this behaviour, so that the dlls get different names for 32 and 64 bit, such as boost_date_time-vc80_x64-mt-1_33_1.dll for 64 bit? Thanks. -- Anders

3 2

Optimized portable isnan, isfinite, fpclassify etc
by Johan Råde 17 Oct '06

17 Oct '06

I have put together optimized implementations of the following functions: template<class T> int fpclassify(T x); template<class T> bool isfinite(T x); template<class T> bool isinf(T x); template<class T> bool isnan(T x); template<class T> bool isnormal(T x); template<class T> bool signbit(T x); template<class T> T copysign(T x, T y); template<class T> T changesign(T x); Here T is required to be float, double or long double. -------------------- The code has been tested with Windows / VC7.1 / i386 Mac / GCC 4.0 / powerpc Linux / GCC 3.3 / i386, amd64, ia64, powerpc, mips, hppa The code should work with most platforms that support the IEEE754 standard. -------------------- Many of these functions have also been implemented by John Maddock. The difference is that my implementation is optimized for speed. Here are some timing numbers on VC 7.1: float Råde Maddock Native fpclassify 8 57 - isfinite 5 57 - isnormal 6 59 - isinf 5 57 - isnan 6 57 - double Råde Maddock Native fpclassify 13 52 29 isfinite 11 56 17 isnormal 14 56 - isinf 10 52 - isnan 4 52 19 The times are in clock cycles for a single call, based on an average of 10,000,000 calls with random input. -------------------- The code is available in the vault, at "Home/Math - Numerics/fpclassify.zip". Many thanks to Håkan Ardö who tested the code on Linux and Olivier Verdie who tested the code on Mac. --Johan Råde

10 51

[iostreams] info on msvc regressions
by David Deakins 17 Oct '06

17 Oct '06

I spent some time this morning looking at the regressions that are being reported for compression tests in the Boost.Iostreams library on MSVC 8. I came across what I think is an omission in the v2 Jamfiles for iostreams. At the moment, the bzip2, glib, and zlib tests are failing with a link error on VC8 saying that the iostreams import library is not found. As it turns out, no import library is being created because the library's build Jamfile.v2 does not specify the BOOST_IOSTREAMS_DYN_LINK=1 define for DLL builds, so the __declspec(dllexport) tag is not used (and then, of course, VC8 does not make the empty import library). I think the last lines of the iostreams build Jamfile.v2 should read: lib boost_iostreams : $(sources) : <link>shared:<define>BOOST_IOSTREAMS_DYN_LINK=1 ; rather than just: lib boost_iostreams : $(sources) ; In addition, it appears that something similar should be included for the 3 compression tests in the test Jamfile.v2 (so that __declspec(dllimport) gets used). For example the bzip2_test should probably be something like: all-tests += [ test-iostreams bzip2_test.cpp ../build//boost_iostreams : <link>shared:<define>BOOST_IOSTREAMS_DYN_LINK=1 ] ; instead of just: all-tests += [ test-iostreams bzip2_test.cpp ../build//boost_iostreams ] ; and a similar change for the gzip_test and zlib_test. With those adjustments, these tests build and pass on my MSVC8 installation. If this all looks correct, hopefully someone can apply those changes to the jamfiles. Thanks, -Dave

2 1

type traits / linkage and generic programming
by Herve Bronnimann 17 Oct '06

17 Oct '06

[Apologies for duplicates, I don't know if an earlier posting went through because I wasn't subscribed under this email address] Dear boosters: According to the C++ standard, language linkage is part of the specification of a type and even though on many platforms two function types with different linkage specs (eg. C and C++ language linkage) are the same, the standard states rather unambiguously ([7.5 decl.link]) "Two function types with different language linkages are distinct types even if they are otherwise identical." My question: does anyone know of a technique to determine the linkage of a function type at compile time? I'm not sure that that would matter for my purposes, but the question arose and I couldn't find an answer. Thanks for any feedback, --Herve Bronnimann PS: here's a concrete example of what I'm asking, a metafunction LinkageTraits that would make the following example compile (code obviously untested - all errors mine): #include <boost/static_assert.h> #include <boost/type_traits.h> struct CPPLinkageTag {}; struct CLinkageTag {}; extern "C" { typedef void functionWithCLinkageType(); } typedef void functionWithCPPLinkageType(); main() { BOOST_STATIC_ASSERT( boost::is_same<LinkageTraits<functionWithCLinkageType>::type, CLinkageTag >::value ); BOOST_STATIC_ASSERT( boost::is_same<LinkageTraits<functionWithCPPLinkageType>::type, CPPLinkageTag >::value ); }

3 2

placeholders and g++ 4.1.1
by Geoff Wedig 17 Oct '06

17 Oct '06

I am attempting to port our source, which makes heavy use of boost, to RHEL5 with gcc version 4.1.1-18. I am getting 'defined but not used' warnings from placeholders.hpp. Since we've got a clean build policy, we need to clean this up somehow. I've done a bit of googling on both the boost site and the internet trying to determine where this error appeared from since our other compiles don't show it. Anyway, has anyone else seen this? I'd like to figure out a work around, or, barring that, a way to suppress it, but I have to admit that I'm not an expert with g++ flags, and I'd like to leave as much warning information intact as possible, of course. Anyone have any ideas?

2 4

Returned mail: see transcript for details
by dave＠boost-consulting.com 17 Oct '06

17 Oct '06

The original message was received at Tue, 17 Oct 2006 10:08:09 +0400 from boost-consulting.com [211.254.227.28] ----- The following addresses had permanent fatal errors ----- <boost(a)lists.boost.org>

1 0

Variadic Templates Redux
by Doug Gregor 17 Oct '06

17 Oct '06

A while ago I announced the availability of an implementation of "variadic templates" for GCC. Variadic templates eliminate a huge amount of redundancy in several Boost libraries (including some that have gone into TR1), such as tuples, function, bind, mem_fn, and MPL. I have now completed the compiler (everything I've thought to try works) and completely reimplemented TR1's <tuple> and <functional> headers using variadic templates. The resulting code is much smaller, clean, and compiles significantly faster that the previous versions. Compiler binaries and sources, both including the implementation of TR1, are available here: http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html I think variadic templates are a big step forward for C++ libraries that deal with function objects, forwarding, and type-lists. If you're interested, please read the documentation, hack some code with the compiler, and tell your local C++ committee representative to vote for variadic templates in C++0x :) Cheers, Doug

17 59

Notice: root/Jamfile.v2 changes.
by Rene Rivera 17 Oct '06

17 Oct '06

This is a gentle warning that I just checked in some cleanup changes to the root Jamfile.v2 file on both HEAD and RC_1_34_0. The cleanups are for the name generation of libraries. I'll be watching to see if this causes problems with the regressions. But if someone spots problems, the sooner I know the better. So please yell, or equivalent thereof, towards me if something is amiss. Thanks for paying attention ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

1 0