December 2007 - Boost - lists.preview.boost.org

HP-UX_ia64_aCC and Boost 1.35
by Boris Gubenko 03 Dec '07

03 Dec '07

HP-UX_ia64_aCC is all green on the trunk except Interprocess library is marked as not supported. Assuming that the results on the release branch are as good as on the trunk (which is something we don't know at this point), would you be willing to consider adding HP-UX/aCC to the list of release platforms for 1.35, under the condition that Interprocess library does not have to be supported in 1.35 on this platform? To assess what the situation with 1.35 is, can I do a test run against release branch and, if so, what's the process? Just pass "--tag=branches/release" to run.py? Thanks, Boris

4 9

[function_types] Eliminating or marking up failures?
by Beman Dawes 03 Dec '07

03 Dec '07

Tobias, function_types is showing 36 failures. What is the plan to eliminate or mark these up as expected? Thanks, --Beman |function_types| fast_mem_fn_example: msvc-7.1 interface_example: msvc-7.1 member_ccs: darwin-4.0.1 darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 member_ccs_exact: darwin-4.0.1 darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 nonmember_ccs: darwin-4.0.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 nonmember_ccs_exact: darwin-4.0.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64

2 3

cv_state has not been declared
by Barco You 03 Dec '07

03 Dec '07

Hi, I'm tring to include boost/thread/mutex.hpp, but when I do compiling, there is an error message: cv_state has not been declared. What's the problem? how should I solve it? Suggestion would be appreciated, thanks! -- ------------------------------- Enjoy life! Barco You

2 6

[1.35.0] Release criteria compilers
by Beman Dawes 02 Dec '07

02 Dec '07

In doing a postmortem of the past couple of releases with Thomas Witt, he made a very strong case that testing is a major bottleneck. If developers and release managers have to wait several days to find out if a fix works, it slows progress to a crawl. One of the things we can do to eliminate that bottleneck is to cut the number of release criteria compilers down to a more manageable number, and to compilers where testing is very reliably and runs several times a day. My candidates for the release criteria compilers are: * Microsoft VC++ 8.0 on Win32 * Intel 10.0 on Win32 * GCC on Linux * GCC on Darwin I've got all of those here, so can verify test results myself if necessary. I expect people will want to add several others, and that's OK. But for this first release on our quarterly schedule, let's keep the number down to be sure we meet our targets. Comments? --Beman

24 56

[boost.test] Floating point comparison fails to compile with templated value type
by Hugo Duncan 02 Dec '07

02 Dec '07

Hi, I was wanting to check two boost::numeric::interval's for closeness, but find I get a compile error. The below fails to compile, with the error messages shown. I believe this is because i) the comparison operator for interval is templated, ii) boost.test wraps one of the values with a readonly_property and therefore the template is not an exact match. Changing the tolerance to an interval does not change anything. This is with MSVC8 and with gcc 3.4.4 on windows. Is this a bug, a missing feature - or am I misusing BOOST_CHECK_CLOSE ? #define BOOST_AUTO_TEST_MAIN #include <boost/test/auto_unit_test.hpp> #include <boost/test/floating_point_comparison.hpp> #include "boost/numeric/interval.hpp" #include "boost/numeric/interval/io.hpp" using boost::unit_test::test_suite; BOOST_AUTO_TEST_CASE(test_interval) { boost::numeric::interval<double> v1=1; boost::numeric::interval<double> v2=1; BOOST_CHECK_CLOSE(v1,v2,1e-5); } c:\cygwin\home\duncan\boost\boost/test/floating_point_comparison.hpp(184) : error C2679: binary '<=' : no operator found which takes a right-hand operand of type 'const boost::unit_test::readonly_property<PropertyType>' (or there is no acceptable conversion) with [ PropertyType=boost::numeric::interval<double> ] c:\cygwin\home\duncan\boost\boost/numeric/interval/interval.hpp(82): could be 'bool boost::numeric::interval<T>::operator <=(const boost::numeric::interval<T>::interval_holder &) const' with [ T=double ] c:\cygwin\home\duncan\boost\boost/numeric/interval/interval.hpp(89): or 'bool boost::numeric::interval<T>::operator <=(const boost::numeric::interval<T>::number_holder &) const' with [ T=double ] while trying to match the argument list '(boost::numeric::interval<T>, const boost::unit_test::readonly_property<PropertyType>)' with [ T=double ] and [ PropertyType=boost::numeric::interval<double> ]

2 1

futures, deadlocking and mutual recursion.
by Achilleas Margaritis 02 Dec '07

02 Dec '07

Isn't there a deadlock issue with futures? suppose I have the following code: class A { int data; public: int getData() const { return data; } void someAction(B *b) { future<int> i = bind(b, &B::someAction, this); data = i.wait() + 1; } }; class B { int data; public: int someAction(A *a) { future<int> j = bind(a, &A::getData); return j.wait() + 1; } }; int main() { A *a = new A; B *b = new B; a->someAction(b); } The above contains a deadlock: class A builds a future 'i' in function 'someAction' over class B, then it waits for B's method 'someAction' to wait. class B, when its method 'someAction' is invoked, builds a future 'j' over method 'getData' of A...then it tries to evaluate 'j'. At this point, the instance of A is blocked waiting for B to finish its processing, and B waits for A to finish its processing, thus deadlocking the program. My question is: is this a real problem, and if so, how is it handled by boost::futures? Another way to introduce the deadlock is by mutual recursion using futures.

3 3

Boost.Test tests require write access in current directory
by David Abrahams 02 Dec '07

02 Dec '07

In particular, the tests that use output_test_stream supply filenames that are interpreted relative to the current working directory. That's not the best possible practice, for reasons of "hygiene:" if testing Boost causes the Boost tree to be modified, it's hard to be sure that one is testing the same thing the next time around. Furthermore, it means one can't test from within a read-only copy of the Boost sources. This bit me as I tested from an NFS-mounted working copy. I realize that Boost.Test may not want to depend on something like Boost.Filesystem, but it seems to me that any decent testing framework has to be able to get ahold of a temporary directory anyway, so maybe the ability to create files in /tmp or %TEMP% should be part of the library? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 4

[Report] 204 failures on trunk (2007-12-02)
by Douglas Gregor 02 Dec '07

02 Dec '07

Boost regression test failures Report time: 2007-12-02T11:13:47Z This report lists all regression test failures on release platforms. Detailed report: http://boost.org/regression/trunk/developer/issues.html 204 failures in 21 libraries concept_check (2) conversion (1) date_time (1) dynamic_bitset (3) function_types (36) fusion (2) gil (9) graph (10) lambda (1) math (1) mpl (2) numeric/interval (12) ptr_container (1) python (9) regex (3) serialization (95) spirit (6) test (5) thread (2) tr1 (1) utility (2) |concept_check| where: intel-linux-9.0 intel-vc8-win-10.0 |conversion| lexical_cast_test: darwin-4.0.1 |date_time| testtime_serialize_xml: darwin-4.0.1 |dynamic_bitset| dyn_bitset_unit_tests3: gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 |function_types| fast_mem_fn_example: msvc-7.1 interface_example: msvc-7.1 member_ccs: darwin-4.0.1 darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 member_ccs_exact: darwin-4.0.1 darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 nonmember_ccs: darwin-4.0.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 nonmember_ccs_exact: darwin-4.0.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 |fusion| deduce_sequence: intel-vc8-win-10.0 repetitive_view: intel-vc8-win-10.0 |gil| channel: intel-vc8-win-10.0 image: gcc-4.1.2_sunos_i86pc intel-vc8-win-10.0 image_io: gcc-4.1.2_sunos_i86pc main: gcc-4.1.2_sunos_i86pc intel-vc8-win-10.0 pixel: gcc-4.1.2_sunos_i86pc intel-vc8-win-10.0 pixel_iterator: gcc-4.1.2_sunos_i86pc |graph| betweenness_centrality_test: gcc-4.2.1_linux_x86_64 csr_graph_test: msvc-8.0_64 cycle_ratio_tests: intel-vc8-win-10.0 msvc-8.0 floyd_warshall_test: gcc-4.2.1_linux_x86_64 graphml_test: intel-vc8-win-10.0 msvc-8.0 graphviz_test: intel-vc8-win-10.0 msvc-8.0 matching_test: gcc-4.2.1_linux_x86_64 |lambda| operator_tests_simple: msvc-7.1 |math| test_policy_2: intel-vc8-win-10.0 |mpl| is_seq: intel-vc8-win-10.0 token_equal: intel-vc8-win-10.0 |numeric/interval| det: msvc-8.0_64 mul: darwin-4.0.1 darwin-4.0.1 msvc-8.0_64 overflow: darwin-4.0.1 darwin-4.0.1 msvc-8.0_64 pi: darwin-4.0.1 darwin-4.0.1 msvc-8.0_64 pow: msvc-8.0_64 test_float: msvc-8.0_64 |ptr_container| serialization: intel-vc8-win-10.0 |python| bases: intel-linux-9.0 exec: gcc-4.1.2_sunos_i86pc intel-linux-9.0 exec-dynamic: intel-linux-9.0 import_: intel-linux-9.0 object: intel-vc8-win-10.0 pointee: intel-linux-9.0 pointer_type_id_test: intel-linux-9.0 upcast: intel-linux-9.0 |regex| regex_regress_threaded: gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 regex_timer: darwin-4.0.1 |serialization| test_demo_portable_archive: darwin-4.0.1 test_demo_portable_archive_dll: darwin-4.0.1 test_diamond_binary_archive: intel-vc8-win-10.0 test_diamond_binary_archive_dll: intel-vc8-win-10.0 test_diamond_text_archive: intel-vc8-win-10.0 test_diamond_text_archive_dll: intel-vc8-win-10.0 test_diamond_text_warchive: intel-vc8-win-10.0 test_diamond_text_warchive_dll: intel-vc8-win-10.0 test_diamond_xml_archive: intel-vc8-win-10.0 test_diamond_xml_archive_dll: intel-vc8-win-10.0 test_diamond_xml_warchive: intel-vc8-win-10.0 test_diamond_xml_warchive_dll: intel-vc8-win-10.0 test_exported_binary_archive: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 test_exported_binary_archive_dll: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 test_exported_text_archive: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 test_exported_text_archive_dll: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 test_exported_text_warchive: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 test_exported_text_warchive_dll: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 test_exported_xml_archive: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 test_exported_xml_archive_dll: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 test_exported_xml_warchive: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 test_exported_xml_warchive_dll: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 test_inclusion: intel-vc8-win-10.0 test_mult_archive_types: intel-vc8-win-10.0 test_mult_archive_types_dll: intel-vc8-win-10.0 test_no_rtti_binary_archive: intel-vc8-win-10.0 test_no_rtti_binary_archive_dll: intel-vc8-win-10.0 test_no_rtti_text_archive: intel-vc8-win-10.0 test_no_rtti_text_archive_dll: intel-vc8-win-10.0 test_no_rtti_text_warchive: intel-vc8-win-10.0 test_no_rtti_text_warchive_dll: intel-vc8-win-10.0 test_no_rtti_xml_archive: intel-vc8-win-10.0 test_no_rtti_xml_archive_dll: intel-vc8-win-10.0 test_no_rtti_xml_warchive: intel-vc8-win-10.0 test_no_rtti_xml_warchive_dll: intel-vc8-win-10.0 test_shared_ptr_132_binary_archive: intel-vc8-win-10.0 test_shared_ptr_132_binary_archive_dll: intel-vc8-win-10.0 test_shared_ptr_132_text_archive: intel-vc8-win-10.0 test_shared_ptr_132_text_archive_dll: intel-vc8-win-10.0 test_shared_ptr_132_text_warchive: intel-vc8-win-10.0 test_shared_ptr_132_text_warchive_dll: intel-vc8-win-10.0 test_shared_ptr_132_xml_archive: intel-vc8-win-10.0 test_shared_ptr_132_xml_archive_dll: intel-vc8-win-10.0 test_shared_ptr_132_xml_warchive: intel-vc8-win-10.0 test_shared_ptr_132_xml_warchive_dll: intel-vc8-win-10.0 test_shared_ptr_binary_archive: intel-vc8-win-10.0 test_shared_ptr_binary_archive_dll: intel-vc8-win-10.0 test_shared_ptr_text_archive: intel-vc8-win-10.0 test_shared_ptr_text_archive_dll: intel-vc8-win-10.0 test_shared_ptr_text_warchive: intel-vc8-win-10.0 test_shared_ptr_text_warchive_dll: intel-vc8-win-10.0 test_shared_ptr_xml_archive: intel-vc8-win-10.0 test_shared_ptr_xml_archive_dll: intel-vc8-win-10.0 test_shared_ptr_xml_warchive: intel-vc8-win-10.0 test_shared_ptr_xml_warchive_dll: intel-vc8-win-10.0 |spirit| scanner_value_type_tests: gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 scanner_value_type_tests_debug: gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 |test| prg_exec_fail3: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 |thread| test_shared_mutex: gcc-4.2.1_linux_x86_64 test_shared_mutex_lib: gcc-4.2.1_linux_x86_64 |tr1| std_test_function: gcc-4.2.1 |utility| value_init_test: darwin-4.0.1 darwin-4.0.1

1 0

[serialization] including shared_ptr_132.hpp triggers namespace bug in VC8+SP1
by Sean Huang 02 Dec '07

02 Dec '07

It seems that the "using namespace boost" statements in shared_ptr_132.hpp and shared_count_132.hpp trigger a problem in VC8 + SP1. Try the following small program: #include <boost/serialization/shared_ptr_132.hpp> #include <boost/cstdint.hpp> typedef unsigned short uint16_t; int main(int argc, char* argv[]) { uint16_t u; return 0; } Will result in this error: error C2872: 'uint16_t' : ambiguous symbol The workaround implemented for Borland works around the bug in VC8 too: #if !BOOST_WORKAROUND( BORLANDC, BOOST_TESTED_AT( 0x560) ) using namespace boost; #endif This problem was submitted to boost Trac (Ticket #1285). Unfortunately, the ticket was closed as "wontfix". Regards, Sean _________________________________________________________________ Put your friends on the big screen with Windows Vista® + Windows Live™. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC…

1 0

[Boostbook] Getting Started download packages for Windows without Cygwin
by Edward Diener 02 Dec '07

02 Dec '07

In Boostbook in the getting started documentation, the download for xsltproc for Windows without Cygwin lists the link http://www.meta-comm.com/engineering/boost/xsltproc-win32.zip . While this does get one a zip file including xsltproc.exe and DLLs needed by it, the implementation which it has is buggy. The implementation includes the files xsltproc.exe, iconv.dll, libexslt.dll, libxml2.dll, libxslt.dll, and zlib1.dll. The latest versions of these in the appropriate distributions for Windows fix the bugs in the distribution above. The distribution above should be replaced by the appropriate files from the latest versions for iconv, libxml2, libxslt, and zlib. The latest versions of these individual distributions can be retrieved from http://www.zlatkovic.com/pub/libxml/ . Keeping the buggy version at the metacomm site simply means that other programmers hoping to use xsltproc to build Boost documentation in Boostbook and Quickbook format will just fail intermittently with the buggy version. To whomever is in charge of updating the xsltproc-win32.zip in the link above, I will be glad to send via e-mail the xsltproc-win32.zip which works correctly to replace the buggy version or, if given an ftp address with write access, I will be glad to upload the correct version, which contains the latest files.

1 0