- Boost - lists.boost.org

Boost regression notification (2005-09-13 [HEAD])
by Douglas Gregor 13 Sep '05

13 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-13T05:00:21Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. typeof concept_check Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 262 failures in 17 libraries: algorithm/string (1) concept_check (11) date_time (5) filesystem (16) foreach (7) graph (25) iostreams (1) math (6) mpl (2) parameter (14) python (1) regex (36) serialization (40) spirit (2) thread (24) typeof (66) wave (5) |algorithm/string| regex: gcc-3_3-darwin |concept_check| stl_concept_covering: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 vc-7_1 |date_time| testlocal_time_iterator: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc testlocal_time_period: gcc-2.95.3-linux msvc |filesystem| convenience_test: gcc-3_4_3-sunos msvc default_name_check_test: gcc-3_4_3-sunos msvc fstream_test: gcc-3_4_3-sunos msvc large_file_support_test: gcc-3_4_3-sunos msvc operations_test: gcc-3_4_3-sunos msvc operations_test_dll: gcc-3_4_3-sunos msvc path_test: gcc-3_4_3-sunos msvc path_test_dll: gcc-3_4_3-sunos msvc |foreach| user_defined: cw-8_3 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| betweenness_centrality_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux gcc-3_4_3-sunos mingw-3_4_2 dag_longest_paths: gcc-3.4.4-linux gcc-3_4_3-sunos mingw-3_4_2 dijkstra_cc: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux gcc-3_4_3-sunos mingw-3_4_2 dijkstra_heap_performance: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux gcc-3_4_3-sunos mingw-3_4_2 graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 relaxed_heap_test: gcc-3.4.4-linux gcc-3_4_3-sunos mingw-3_4_2 |iostreams| regex_filter_test: gcc-3_3-darwin |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |parameter| basics: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux macros: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc unnamed: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| data_members: msvc |regex| bad_expression_test: gcc-3_3-darwin captures_example: gcc-3_3-darwin captures_test: gcc-3_3-darwin collate_info: gcc-3_3-darwin concept_check: gcc-3_3-darwin credit_card_example: gcc-3_3-darwin grep: gcc-3_3-darwin icu_example: gcc-3_3-darwin mfc_example: gcc-3_3-darwin object_cache_test: gcc-3_3-darwin partial_regex_grep: gcc-3_3-darwin partial_regex_match: gcc-3_3-darwin posix_api_check: gcc-3_3-darwin posix_api_check_cpp: gcc-3_3-darwin recursion_test: gcc-3_3-darwin regex_config_info: gcc-3_3-darwin regex_dll_config_info: gcc-3_3-darwin regex_grep_example_1: gcc-3_3-darwin regex_grep_example_2: gcc-3_3-darwin regex_grep_example_3: gcc-3_3-darwin regex_grep_example_4: gcc-3_3-darwin regex_iterator_example: gcc-3_3-darwin regex_match_example: gcc-3_3-darwin regex_merge_example: gcc-3_3-darwin regex_regress: gcc-3_3-darwin regex_regress_dll: gcc-3_3-darwin regex_replace_example: gcc-3_3-darwin regex_search_example: gcc-3_3-darwin regex_split_example_1: gcc-3_3-darwin regex_split_example_2: gcc-3_3-darwin regex_timer: gcc-3_3-darwin regex_token_iterator_eg_1: gcc-3_3-darwin regex_token_iterator_eg_2: gcc-3_3-darwin static_mutex_test: gcc-3_3-darwin msvc wide_posix_api_check_cpp: gcc-3_3-darwin |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_barrier: msvc test_barrier_lib: intel-9.0-linux msvc test_condition: msvc test_condition_lib: intel-9.0-linux msvc test_mutex: msvc test_mutex_lib: intel-9.0-linux msvc test_once: msvc test_once_lib: intel-9.0-linux msvc test_read_write_mutex: msvc test_read_write_mutex_lib: intel-9.0-linux msvc test_thread: msvc test_thread_lib: intel-9.0-linux msvc test_tss: msvc test_tss_lib: intel-9.0-linux msvc test_xtime: msvc test_xtime_lib: intel-9.0-linux msvc |typeof| data_member_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux data_member_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 function_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 msvc function_ptr_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ptr_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 function_ref_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ref_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 lvalue_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lvalue_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 msvc member_function_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 modifiers_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 template_int_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_int_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 template_tpl_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_tpl_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 msvc template_type_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 type_emulation: borland-5_6_4 cw-8_3 cw-9_4 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux gcc-3_4_3-sunos intel-9.0-linux

1 0

Re: [boost] [serialization] No Reply?
by JOAQUIN LOPEZ MU?Z 13 Sep '05

13 Sep '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Lunes, Septiembre 12, 2005 11:06 pm Asunto: Re: [boost] [serialization] No Reply? > * You should find some way to describe what it means for an input > and an output archive to be compatible. Try to do that as > formally as possible. You may have to rely on the fuzzy C++ > notion of "equivalence," but I wouldn't blame you for that. IMHO, there's no need to go fuzzy or rely on an undefined notion of "equivalence" between a serialized object and its restored copy. One can define these concepts with much precision in an "operational semantics" way, much as, for instance, semantics of logic languages is formally defined: * A type T is serializable if the expressions oar<<ct; iar>>t; are valid, where ct is of type const T& and t is of type T&, oar is an output archive and iar is an input archive. * The storage sequence, or simply storage, of an output archive oar is the ordered sequence of *all* calls s(i) of the form: oar<<out(i); where out(i) is of type const T(i)&. * Given an output archive oar with storage s(i) such that every T(i) is serializable, we say that an input archive iar is associated to oar if the sequence of expressions iar>>in(i); where in(i) is of type T(i)&, does not throw. We assume the input sequence ranges over the entire lifetime of iar. * Under the assumptions above, we say that in(i) is a restored copy of out(i). This defines association between archives in an abstract way. We can go concrete on a per archive basis, for instance: * Given an text output archive oar dumping to a file ofl, and an text input archive iar reading from a file if, iar is associated to oar if the contents of ifl coincide with those of ofl. Now that we have defined what it means for an input archive to be associated to an output archive, we can define the operational semantics of serialization from the concept "being a restored copy". In what follows we use the previous notation. The idea is to begin with primitive types and build on those. * If in(i) is of type bool&, in(i)==true if and only if out(i)==true. * If in(i) is of type char&, the numerical value of in(i) is that of out(i). * Similarly for other integral types. Different word sizes should be taken into account. * If in(i) is of type T*&, and T is serializable, *in(i) is a restored copy of *out(i). We can extend this schema inductively as we progress to more complex types. For example: * If in(i) is of type std::vector<T>&, and T is serializable, then in(i).size()==out(i).size() and each in(i)[j] is a restored copy of out(i)[j]. IMHO, this is sufficiently formal and solves two theoretical issues: * We have defined association between output and input archives without mentioning extralinguistical devices (files, network streams, and so on.) * We have a satisfactory definition of what serialization is supposed to do without relying on a naive "equivalence" relationship between objects and their restored copies: the main difficulty of such a naive approach like for instance "the restored copy has the same value as the original object", is that it does not mean much when these objects belong to different programs, running on different timeframes and perhaphs on different platforms. What do you think? Admittedly, what I've written still has some edges to rough, but I think it is sound enough. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[serialization]: test_diamond partly untested in release mode.
by Stefan Seefeld 13 Sep '05

13 Sep '05

I'm looking for references in boost library tests as to how to use BOOST_ASSERT correctly. I thus found the test_diamond tests in boost/serialization. It appears that the way BOOST_ASSERT is used there doesn't do anything in release mode, i.e. the expression isn't evaluated at all. (I modified the expression and the test still passed.) (As it happens, I was looking specifically for applications of http://www.boost.org/libs/utility/assert.html, as I want to use it in my own tests.) Regards, Stefan

2 1

stlport toolset patches
by François Dumont 13 Sep '05

13 Sep '05

Here is a first patch to build boost using STLport 5.0 with MSVC compilers. STLport 5.0 has adopt a more simple naming schema for generated library, compiler name is not part of it anymore. Rather than changing existing variable in the .jam files I prefered to introduce a new variable STLPORT_USE_AUTO_LINK to signal support of the auto link feature. In this case no lib is specified at link phase, STLport takes care of it. Any remark on the patches will be welcome as I am a completely beginner with bjam. What I would like to achieve now is reflect in bajm files that 5.0 do not support 'wrapper' mode anymore, stlport-iostream feature has to be on per default with this version, is it possible? Bests *** msvc-stlport-tools.jam.orig Thu Aug 25 05:10:34 2005 --- msvc-stlport-tools.jam Thu Aug 25 16:36:23 2005 *************** *** 13,18 **** --- 13,19 ---- STLPORT_LIB_BASE_NAME ?= stlport_vc6 ; STLPORT_LIB_STATIC_SUFFIX ?= _static ; + STLPORT_USE_AUTO_LINK = yes ; # bring in the STLPort configuration SEARCH on stlport.jam = $(BOOST_BUILD_PATH) ; *** stlport.jam.orig Thu Aug 25 05:11:22 2005 --- stlport.jam Thu Aug 25 16:37:06 2005 *************** *** 105,111 **** flags $(CURR_TOOLSET) DEFINES <runtime-build>debug : _STLP_DEBUG=1 _STLP_DEBUG_UNINITIALIZED=1 ; flags $(CURR_TOOLSET) DEFINES <runtime-link>dynamic : _STLP_USE_DYNAMIC_LIB=1 ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; --- 105,114 ---- flags $(CURR_TOOLSET) DEFINES <runtime-build>debug : _STLP_DEBUG=1 _STLP_DEBUG_UNINITIALIZED=1 ; flags $(CURR_TOOLSET) DEFINES <runtime-link>dynamic : _STLP_USE_DYNAMIC_LIB=1 ; ! if ! $(STLPORT_USE_AUTO_LINK) ! { ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; ! } *** vc7-stlport-tools.jam.orig Thu Aug 25 05:21:13 2005 --- vc7-stlport-tools.jam Thu Aug 25 16:36:40 2005 *************** *** 3,8 **** --- 3,9 ---- flags $(gCURRENT_TOOLSET) STLPORT_LIB_BASE_NAME ; STLPORT_LIB_BASE_NAME ?= stlport_vc70 ; + STLPORT_USE_AUTO_LINK ?= yes ; # bring in the STLPort configuration SEARCH on stlport.jam = $(BOOST_BUILD_PATH) ;

3 3

Re: [boost] Boost regression notification (2005-09-03 [HEAD])
by Martin Bonner 13 Sep '05

13 Sep '05

Doug Gregor [mailto:dgregor@cs.indiana.edu] wrote: >> Somebody wrote: >>>> It looks like some code isn't handling the improved "long double" >>>> type very well.... (With Mac OS X Tiger 10.4 and GCC 4, the >>>> "long double" type is finally distinct and bigger than "double". >>>> The pre-Tiger warnings about not using "long double" are >>>> obviously removed. But it looks like the "double" version of >>>> "exp" is being used. Taking a quick look at a system "math.h"... > > I've traced through this, and the right "exp" is getting called. The > machine epsilon for long double is: > > 4.9406564584124654417656879286822137236505980261432476442558568250067550 > 727020875e-324 Are you sure that's right? That implies a 1074-bit mantissa. That's a VERY long double! (It is also a rather odd sized one. In such a large type, I would expect the mantissa to be an exact number of bytes - or mantissa+sign to be an exact number of bytes). That value looks much more reasonable for the smallest non-zero value of long double. (I am assuming that by epsilon you mean the smallest values such that 1+epsilon != 1, rather than the smallest value such that epsilon > 0). > > There's no *way* we'll get that much accuracy out of the C library's > sin/atan/cos/etc. Here's the result of a little program that prints > out atan(1), 4*atan(1), and sin(4*atan(1)). There isn't a large enough > improvement in precision from "double" to "long double": > > atan(1) with float = 0.785398185253143310546875 > 4*atan(1) with float = 3.1415927410125732421875 > sin(4*atan(1)) with float = > -8.74227765734758577309548854827880859375e-08 > atan(1) with double = > 0.78539816339744827899949086713604629039764404296875 > 4*atan(1) with double = > 3.141592653589793115997963468544185161590576171875 > sin(4*atan(1)) with double = > 1.224606353822377258211417938582599163055419921875e-16 > atan(1) with long double = > 0.7853981633974483096282022398515465511081856675446033477783203125 > 4*atan(1) with long double = > 3.14159265358979323851280895940618620443274267017841339111328125 > sin(4*atan(1)) with long double = > -5.42101086242752217003726400434970855712890625e-20 If long double is actually 80 bits (which is the usual Intel interpretation), that looks plausible. > I don't even think that we can call this a platform bug; we just can't > expect the C library routines to have that kind of precision. If long double really is >1kbits, I don't see why the C runtime shouldn't support them. > I think > we should consider long double tests on this platform bogus and > disable them. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

[Boost.Thread]: consider removing catch(...) from thread_proxy
by Slawomir Lisznianski 13 Sep '05

13 Sep '05

Hello, I find the catch(...) clause in the thread_proxy function (thread.cpp) causing more harm than good. If exception "leaks" from a function executing in the context of a thread, the thread silently goes away but the application continues to operate as if nothing happend. I think, in this instance, the library simply "does too much" by trying to do the cleanup. As a user, I can always wrap the code in the catch-all, but what I cannot change is the fact that when unhandled exception is thrown, I will not see the function in the stack trace where the exception originated. Here is the proposed proxy, after trivial changes: extern "C" { #if defined(BOOST_HAS_WINTHREADS) unsigned __stdcall thread_proxy(void* param) #elif defined(BOOST_HAS_PTHREADS) static void* thread_proxy(void* param) #elif defined(BOOST_HAS_MPTASKS) static OSStatus thread_proxy(void* param) #endif { thread_param* p = static_cast<thread_param*>(param); boost::function0<void> threadfunc = p->m_threadfunc; p->started(); threadfunc(); #if defined(BOOST_HAS_WINTHREADS) on_thread_exit(); #endif #if defined(BOOST_HAS_MPTASKS) ::boost::detail::thread_cleanup(); #endif return 0; } } Regards, Slawomir

14 47

Yet another regression system question
by Arkadiy Vertleyb 12 Sep '05

12 Sep '05

Hi All, Is it possible to use "run" or "link" test types in combination with more than one source (I need this for ODR testing)? If not, how do I define such a test? Thanks, Arkadiy

2 2

[xpressive][review] regex type
by Thomas Witt 12 Sep '05

12 Sep '05

What is the rationale for having the regex type bound to the iterator type used when matching/searching ? Thomas

2 1

[Filesystem] Removed extraneous debugging info
by Douglas Gregor 12 Sep '05

12 Sep '05

Failures in the filesystem library were breaking testing on several of our *nix machines. The problems were due to some extraneous debugging output statements that worked only on Windows. I've checked in the obvious fix to libs/filesystem/src/operations_posix_windows.cpp. Doug

3 2

[Serialization] Pointer to const
by Loïc Joly 12 Sep '05

12 Sep '05

Hello everybody, There a still many stuff I do not understand how to do with boost::serialization. One of them is the following : Let's say I have the following classes : struct B { int i; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & i;} }; struct A { B const *pc; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & pc; } }; When I try to serialize a A, I get the following error (MSVC8 beta 2): c:\boost\include\boost-1_33\boost\archive\detail\iserializer.hpp(474) : error C2440: 'reinterpret_cast' : cannot convert from 'const B **__w64 ' to 'void **' Conversion loses qualifiers c:\boost\include\boost-1_33\boost\archive\detail\iserializer.hpp(471) : while compiling class template member function 'void boost::archive::detail::load_pointer_type<Archive,Tptr>::invoke(Archive &,Tptr &)' with [ Archive=boost::archive::text_iarchive, Tptr=const B * ] Of course, if I replace B const *pc by B *pc, then the code works correctly.What can I do to serialize pointers to const data ? Regards, -- Loïc

2 4