- Boost - lists.boost.org

Boost regression notification (2005-12-08 [HEAD])
by Douglas Gregor 08 Dec '05

08 Dec '05

Boost regression test failures ------------------------------ Report time: 2005-12-07T13:00:18Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 221 failures in 17 libraries: bind (1) concept_check (13) date_time (19) foreach (6) graph (7) io (1) mpl (1) multi_array (6) parameter (1) python (1) serialization (26) smart_ptr (2) spirit (2) tr1 (88) typeof (22) wave (1) xpressive (24) |bind| bind_dm3_test: msvc |concept_check| stl_concept_covering: cw-9_4 cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 msvc vc-7_1 vc-7_1 |date_time| testc_local_adjustor: msvc testclock: msvc testdst_rules: msvc testfiletime_functions: msvc testgreg_duration_operators: msvc testgreg_serialize_dll: cw-9_4 intel-win32-8_1 intel-win32-9_0 vc-7_1 vc-7_1 testiterator: msvc testlocal_adjustor: msvc testmicrosec_time_clock: msvc testparse_time: msvc testtime: msvc testtime_formatters: msvc testtime_period: msvc testwcustom_time_zone: msvc testwposix_time_zone: msvc |foreach| array_byref: cw-9_4 array_byval: cw-9_4 rvalue_const: intel-win32-8_1 intel-win32-9_0 stl_byref: cw-9_4 stl_byval: cw-9_4 |graph| csr_graph_test: cw-9_4 dominator_tree_test: cw-9_4 intel-win32-9_0 vc-7_1 graphviz_test: vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |multi_array| access: cw-9_4 assign: cw-9_4 assign_to_array: cw-9_4 index_bases: cw-9_4 iterators: cw-9_4 slice: cw-9_4 |parameter| sfinae: msvc |python| stl_iterator: msvc |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin 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 |smart_ptr| pointer_to_other_test: msvc shared_ptr_alloc2_test: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |tr1| run_complex_overloads: cw-9_4 std_run_complex_overloads: cw-9_4 std_run_random: cw-9_4 std_test_array: cw-9_4 std_test_bind: cw-9_4 std_test_complex: cw-9_4 std_test_function: cw-9_4 std_test_hash: cw-9_4 std_test_mem_fn: cw-9_4 std_test_random: cw-9_4 std_test_regex: cw-9_4 std_test_result_of: cw-9_4 std_test_tr1_include: cw-9_4 std_test_tuple: cw-9_4 std_test_type_traits: cw-9_4 test_array: cw-9_4 test_bind: cw-9_4 test_complex: cw-9_4 test_function: cw-9_4 test_hash: cw-9_4 test_mem_fn: cw-9_4 test_random: cw-9_4 test_reference_wrapper: cw-9_4 test_result_of: cw-9_4 test_shared_ptr: cw-9_4 test_tr1_include: cw-9_4 test_tuple: cw-9_4 tr1_add_const_test: cw-9_4 tr1_add_cv_test: cw-9_4 tr1_add_pointer_test: cw-9_4 tr1_add_reference_test: cw-9_4 tr1_add_volatile_test: cw-9_4 tr1_aligned_storage_test: cw-9_4 tr1_alignment_of_test: cw-9_4 tr1_extent_test: cw-9_4 tr1_has_nothrow_assign_test: cw-9_4 tr1_has_nothrow_constr_test: cw-9_4 tr1_has_nothrow_copy_test: cw-9_4 tr1_has_tr1_ref_wrap_fail: cw-9_4 tr1_has_tr1_shared_ptr_fail: cw-9_4 tr1_has_tr1_tuple_fail: cw-9_4 tr1_has_trivial_assign_test: cw-9_4 tr1_has_trivial_constr_test: cw-9_4 tr1_has_trivial_copy_test: cw-9_4 tr1_has_trivial_destructor_test: cw-9_4 tr1_has_virtual_destructor_test: cw-9_4 tr1_is_arithmetic_test: cw-9_4 tr1_is_array_test: cw-9_4 tr1_is_base_of_test: cw-9_4 tr1_is_class_test: cw-9_4 tr1_is_compound_test: cw-9_4 tr1_is_const_test: cw-9_4 tr1_is_convertible_test: cw-9_4 tr1_is_empty_test: cw-9_4 tr1_is_enum_test: cw-9_4 tr1_is_floating_point_test: cw-9_4 tr1_is_function_test: cw-9_4 tr1_is_fundamental_test: cw-9_4 tr1_is_integral_test: cw-9_4 tr1_is_member_func_test: cw-9_4 tr1_is_member_obj_test: cw-9_4 tr1_is_member_pointer_test: cw-9_4 tr1_is_object_test: cw-9_4 tr1_is_pod_test: cw-9_4 tr1_is_pointer_test: cw-9_4 tr1_is_polymorphic_test: cw-9_4 tr1_is_reference_test: cw-9_4 tr1_is_same_test: cw-9_4 tr1_is_scalar_test: cw-9_4 tr1_is_signed_test: cw-9_4 tr1_is_union_test: cw-9_4 tr1_is_unsigned_test: cw-9_4 tr1_is_void_test: cw-9_4 tr1_is_volatile_test: cw-9_4 tr1_rank_test: cw-9_4 tr1_remove_all_extents_test: cw-9_4 tr1_remove_const_test: cw-9_4 tr1_remove_cv_test: cw-9_4 tr1_remove_extent_test: cw-9_4 tr1_remove_pointer_test: cw-9_4 tr1_remove_reference_test: cw-9_4 tr1_remove_volatile_test: cw-9_4 tr1_tricky_abstract_type_test: cw-9_4 tr1_tricky_add_pointer_test: cw-9_4 tr1_tricky_function_type_test: cw-9_4 tr1_tricky_incomplete_type_test: cw-9_4 tr1_tricky_is_enum_test: cw-9_4 tr1_tricky_partial_spec_test: cw-9_4 |typeof| data_member_native: cw-9_4 function_native: cw-9_4 msvc function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 msvc member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 msvc template_type_native: cw-9_4 type_native: cw-9_4 |wave| testwave_dll: cw-9_4 |xpressive| misc1: cw-9_4 test1: cw-9_4 test1u: cw-9_4 test2: cw-9_4 test2u: cw-9_4 test3: cw-9_4 test3u: cw-9_4 test4: cw-9_4 test4u: cw-9_4 test5: cw-9_4 test5u: cw-9_4 test6: cw-9_4 test6u: cw-9_4 test7: cw-9_4 test7u: cw-9_4 test8: cw-9_4 test8u: cw-9_4 test9: cw-9_4 test9u: cw-9_4 test_cycles: cw-9_4 test_dynamic: cw-9_4 test_non_char: cw-9_4 test_regex_primitives: cw-9_4 test_static: cw-9_4

1 0

Re: [boost] [boost::throw_exception] and platforms where it don't throw
by Martin Bonner 08 Dec '05

08 Dec '05

----Original Message---- From: Peter Dimov [mailto:pdimov@mmltd.net] Sent: 08 December 2005 15:40 To: boost(a)lists.boost.org Subject: Re: [boost] [boost::throw_exception] and platforms where it don'tthrow > And of course in a situation where throw_exception is used to throw > bad_alloc, an assertion makes even less sense, because there are no > "logic errors" involved, and presenting the effects of a failed > assertion to the end user would serve little purpose; the program > could do nothing to defend itself from the out of memory situation. But if a library is being used in an exception free environment, maybe presenting an assertion failure to the user is as good as you can do. -- 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

[interval] in_zero
by David Abrahams 08 Dec '05

08 Dec '05

Why isn't this function called zero_in? if (zero_in(x)) whatever... seems a lot more natural than if (in_zero(x)) whatever... After all, the question is whether zero is in x, not whether x is in zero! -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

on boost version numbers
by Stefan Seefeld 08 Dec '05

08 Dec '05

Hi there, now that the 1.33.1 release is out, I'd like to bring up again a topic that was discussed (or at least, touched) previously. I see two issues with the current release numbering scheme: 1) What is currently the major version number appears to have lost all its meaning. Why isn't it dropped, making the next release '34' instead of '1.34' ? 2) As was previously stated here, there is no attempt to make versions x.y.z and x.y.(z+1) binary compatible. From a user's perspective there is therefor no difference between version y.(z+1) and (y+1), neither in terms of features, nor in terms of time between releases. I therefor suggest to drop the last component, too. Releases therefor become simply a simple sequence 34, 35, ... This obviously doensn't have any impact on any branching policies, or release planning. It only affects the user's perception of releases and how they relate to each other. Comments ? Thanks, Stefan

12 20

Re: [boost] [wave) experiences
by Hartmut Kaiser 08 Dec '05

08 Dec '05

Vambola Kotkas wrote: > Wave Driver C++ preprocessor seems quite useful tool to see what > happens with most macros. Unfortunatelly it needs some debugging > before it can be used to preprocess real code. For example it refuses > (unneccessarily) to process sometimes. > > Silly example 1: > #if __LINE__ == 11112223334 > #pragma message( "Huh!" ) > #endif > Result: > test.cpp(1): error: ill formed integer literal or integer constant > too > large: 11112223334. > > None of the available wave flags did seemingly help. Not that i need > huge integers, however boost sometimes does have way bigger ones so it > must be legal? MS Visual C++ 7.1 processes constants like > 18446744073709551615 without any noise. > See ... 1.33.0 boost/cstdint.hpp line(263): > # if ULONG_MAX == 18446744073709551615 // 2**64 - 1 It's not legal for 32 bit systems. Either flag the 11112223334 with the LL suffix (and the --long_long command line option) or you are out of luck with Wave. At least as long the code is not hidden inside a non-evaluated #if/#endif block. I've fixed Wave after 1.33.0 to accept large numbers in non-evaluated #if expressions, just to allow to compile Boost. > Silly example 2: > #define SHOW2(x) #x > #define SHOW(x) SHOW2(Number is:##x) > #pragma message( SHOW(__LINE__)) > Result: > test.cpp(3): error: pasting the following two tokens does not give a > valid preprocessing token: ":" and "__LINE__" Concatenating two unrelated tokens isn't allowed by the C++ Standard. If you really need this just provide the --variadics command line option, which will enable certain C99 features in C++ (variadics, token concatination of unrelated tokens etc.) > Maybe its buggy and MS made its preprocessor too lousy there ... just > for reference Visual C++ 7.1 preprocess result: Yes, the MSVC preprocessor is lousy. > Side question: How to force wave to use full paths in #line > directives? > Larger projects may contain similarily named files and people > usually have multiple versions of their own software, nothing > to talk of libraries and SDK-s. Wave does use full paths in #line directives as long as the corresponding files are not in the directory of the main file. > Silly thing 2 can be > transformed into Working thing 2: > #define SHOW2(x) #x > #define SHOW(x) SHOW2(x) > #pragma message("Number is:" SHOW(__LINE__)) Wave produces > same output as VC++ 7.1 then: > #line 3 "test.cpp" > #pragma message("Number is:" "3") What's silly here? > Finally ... fair test for preprocessor is if it preprocesses > its own code. > That makes wave to crash with "unexpected exception caught." > Various sets of -P and -D options make it to crash in various > places. I did not manage to find a good set of options so it > does not crash. How to compile debug version of wave with > vc7.1? bjam "-sBUILD=<debug>" ... ? > Without debugging it is hard to further track down > what is going on there. I tried the wave in boost 1.33.0. Frankly speaking, I haven't done this for a long time. So I tried today and got several errors/warnings reported by Wave (which I have to investigate further), but I didn't get any segfault! I'll report on this list with my findings. Could you please elaborate on which compiler you used to generate Wave, which command line options did you use? Regards Hartmut

9 16

File Vault strangeness
by Eric Niebler 08 Dec '05

08 Dec '05

The download counters for xpressive.zip and foreach.zip dropped to 1 for some reason. I seem to recall this happening before. There seems to be some bug wrt the download counters -- possible some race condition? -- Eric Niebler Boost Consulting www.boost-consulting.com

4 13

Re: [boost] [wave) experiences
by Martin Bonner 07 Dec '05

07 Dec '05

----Original Message---- From: Paul Mensonides [mailto:pmenso57@comcast.net] Sent: 07 December 2005 09:10 To: boost(a)lists.boost.org Subject: Re: [boost] [wave) experiences > Supporting [extended length integers] is not a good idea. > IMO, it is just the beginning of non-standard extensions. > For the purpose of cross-compiling, I don't have a problem > with an option to specify the width. But what about cross compiling from a 32-bit platform for a 64-bit target? (which strikes me as a perfectly reasonable thing to do today). > IMHO, it is in the community's ultimate best interest for > preprocessors and compilers to be as *un-permissive* as possible. ... but in general I agree with this idea. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

4 5

Re: [boost] BOOST_ENUM proposal
by Job Mulder 07 Dec '05

07 Dec '05

It looks nice, but does it also work with other structures than strings? i.e. BOOST_ENUM(id, (ab_device)("device for your abs", /*activation code*/ 13, /*typical % of time used*/ 0.0) (pc_device)("personal computer", /*activation code*/ 42, /*typical % of time used*/ 100.0) ) -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Frank Laub Sent: Wednesday, December 07, 2005 12:47 To: boost(a)lists.boost.org Subject: [boost] BOOST_ENUM proposal Hello fellow boosters, I've recently come up with a way to use the boost preprocesor to generate a 'better' enum type. The following is an example of some typical usage. Is anyone else interested in this sort of thing? I'm hoping to get suggestions for how to make it more 'boost-like' in both its implementation and its usage. Is this very readable? Is there a place I can upload the code for people to peruse? #include <iostream> #include <boost/enum.hpp> #include <boost/foreach.hpp> #define foreach BOOST_FOREACH BOOST_ENUM(Level, (Abort)("unrecoverable problem") (Error)("recoverable problem") (Alert)("unexpected behavior") (Info)("expected behavior") (Trace)("normal flow of execution") (Debug)("detailed object state listings") ) int main() { foreach(const string& name, Level::names) { cout << name << endl; } cout << "1: " << Level::names[1] << endl; cout << "toString(Abort): " << Level::toString(Level::Abort) << endl; cout << "getValue(Abort): " << Level::getValue(Level::Abort) << endl; Level::type value = Level::Invalid; bool ret = Level::fromString("Abort", value); cout << "fromString(\"Abort\"): " << ret << ", " << value << endl; value = Level::Invalid; ret = Level::fromString("Debug", value); cout << "fromString(\"Debug\"): " << ret << ", " << value << endl; value = Level::Invalid; ret = Level::fromString("not in enum", value); cout << "fromString(\"not in enum\"): " << ret << ", " << value << endl; return 0; } With the program output being: Abort Error Alert Info Trace Debug Invalid 1: Error toString(Abort): Abort getValue(Abort): unrecoverable problem fromString("Abort"): 1, 0 fromString("Debug"): 1, 5 fromString("not in enum"): 0, 6 -Frank _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Boost & Threading
by Jens Hibbeler 07 Dec '05

07 Dec '05

Hello Perhaps anyone can give me a hint, how I get ahead or where my error lies? Which I did: 0) Executed Borland builder Patch No. 4 1) Downloaded Spirit 1.6.3, set environment variable SPIRIT_ROOT on the Spirit listing 2) Set environment variable BCCROOT on c:\programme\borland\cbuilder6 3) Dowloaded the Boost LIBRARY (tried one after the other from 1_32-1_33 beta, all versions), and set the BOOST_ROOT environment variable to the listing in which I boost unpacked. 4) At the Boost tools\build\listing\build.bat executed (compiles correctly for Boland) 5) Executed tools\build\jam_src\bin.ntx86\bjam.exe "- sTOOLS=borland" install (compiled also, but with few warnings) 6) At the listing, in which I unpacked Boost, I started the libs\thread\example file once.cpp 7) I made a Porjekt to compile the file 8) I set atthe project settings the include path on C:\Boost\include\boost-1_32 9) I set atthe project attitudes the LIBRARY path on C:\Boost\lib \ 10) The program compiled and linked 11) When starting the project it crhases immediately and started the monitor, which indicates the storage addresses to me. Where does my error lie? Do I have to adjust something special in the Porjekt still? Many greetings from Hamburg, Jens Hibbeler

1 1

Re: [boost] [smart_ptr] BOOST_SP_USE_QUICK_ALLOCATOR andmulti-threading broken on gcc-4.0.2
by Peter Dimov 07 Dec '05

07 Dec '05

Juergen Hunold wrote: > Hi Again ! > > I've taken another attempt to fix this and found a solution. > > On Wednesday 07 December 2005 20:37, Juergen Hunold wrote: >> Question: Is this a bug or a feature ? > > It's a bug. > >> Question: If this is a bug, whats the fix ? > > Please find the fix attached. Applied, thank you. I have no idea how MSVC 7.1 (that I used to test the modification) was able to eat the original horribly broken code, but it managed to.

1 0