October 2005 - Boost - lists.preview.boost.org

Re: [boost] [range][1.33.1] last few regressions.
by boost.regex＠virgin.net 31 Oct '05

31 Oct '05

>I need to spend some more time on the range library before I feel>comfortable about releasing it together with boost.foreach.>I need to change the concept requirements and update the docs and won't have>time until the weekend.Understood, but please remember we're talking about patching the 1.33 release source here, *not* a new updated version: that's a different thing entirely.John.

4 7

Boost regression notification (2005-10-30 [RC_1_33_0])
by Douglas Gregor 31 Oct '05

31 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-30T14:55:09Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 8 failures in 4 libraries: date_time (1) filesystem (2) range (3) serialization (2) |date_time| testtz_database: intel-win32-8_1 |filesystem| operations_test: intel-win32-8_1 operations_test_dll: intel-win32-8_1 |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_demo_xml_load: intel-win32-8_1 test_shared_ptr_132_text_warchive: intel-win32-8_1

6 7

What the?
by Dan McLeran 31 Oct '05

31 Oct '05

Yesterday, I tried upgrading from Boost 1.30 to 1.33 and I got the weirdest reaction from my linker. Some background: I am using MSVC6SP6; The code in question is a dll that runs under PharLap 9.1. I am linking against libcmt as well as a lib called cellexe.lib, which provides all of the C runtime stuff and PharLap-specific OS stuff. With Boost 1.30, everything compiles and links just peachy. When I pointed the project at Boost 1.33, I had to make a couple of small code changes: 1. I had to change boost::mpl::apply_if to boost::mpl::eval_if. 2. I had to stop using TrivialIteratorConcept and switched to ForwardIteratorConcept or RandomAccessIteratorConcept. That's really the only code changes I can think of but now my linker gives me a bunch of warnings and 1 error message, which is what's really killing me: Linking... LIBCMT.lib(typinfo.obj) : error LNK2005: "const type_info::`vftable'" (??_7type_info@@6B@) already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(strtol.obj) : error LNK2005: _strtoul already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(chkstk.obj) : error LNK2005: __chkstk already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(xtoa.obj) : error LNK2005: __ultoa already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(atox.obj) : error LNK2005: _atoi already defined in cellexe.lib(Cellexe.exe) LIBCMT.lib(typinfo.obj) : warning LNK4006: "const type_info::`vftable'" (??_7type_info@@6B@) already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(strtol.obj) : warning LNK4006: _strtoul already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(chkstk.obj) : warning LNK4006: __chkstk already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(xtoa.obj) : warning LNK4006: __ultoa already defined in cellexe.lib(Cellexe.exe); second definition ignored LIBCMT.lib(atox.obj) : warning LNK4006: _atoi already defined in cellexe.lib(Cellexe.exe); second definition ignored Creating library PharLapRelease/Devo.lib and object PharLapRelease/Devo.exp LIBCMT.lib(crt0.obj) : error LNK2001: unresolved external symbol _main PharLapRelease/Devo.dll : fatal error LNK1120: 1 unresolved externals Error executing link.exe. I can't understand why the linker is now searching for _main when the project is a dll and I have all the necessary stuff: .def file, /dll switch, etc. I have compiled and run this dll for literally years when using Boost 1.30. Can anyone think of anything in this Boost library upgrade that could cause this? Keep in mind that I did not change any project setting other than the include directories to point the compiler at the directories containing Boost 1.33 and that I have been using this code along with Boost 1.30 for years.

3 4

Boost regression notification (2005-10-31 [HEAD])
by Douglas Gregor 31 Oct '05

31 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-31T06:00:27Z 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. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 290 failures in 14 libraries: concept_check (12) filesystem (2) graph (2) io (1) mpl (1) python (1) serialization (30) spirit (8) thread (4) tr1 (147) tuple (1) type_traits (58) typeof (18) xpressive (5) |concept_check| stl_concept_covering: cw-9_4 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 gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 vc-7_1 |filesystem| operations_test: intel-win32-9_0 operations_test_dll: intel-win32-9_0 |graph| graphviz_test: 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 |python| exec: intel-win32-9_0 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: 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: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: 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 |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tr1| run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux run_random: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux std_test_array: gcc-2.95.3-linux std_test_array_tricky: 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 intel-win32-9_0 vc-7_1 std_test_bind: 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 intel-win32-9_0 std_test_bind_tricky: 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 intel-win32-9_0 vc-7_1 std_test_boost: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_complex: gcc-2.95.3-linux std_test_function: gcc-2.95.3-linux std_test_function_tricky: 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 intel-win32-9_0 vc-7_1 std_test_hash: gcc-2.95.3-linux std_test_mem_fn: gcc-2.95.3-linux std_test_mem_fn_tricky: 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 intel-win32-9_0 vc-7_1 std_test_random: gcc-2.95.3-linux std_test_reference_wrapper: gcc-2.95.3-linux std_test_reference_wrapper_tricky: 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 intel-win32-9_0 vc-7_1 std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_shared_ptr: gcc-2.95.3-linux std_test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tuple_tricky: 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 intel-win32-9_0 vc-7_1 std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_algorithm: gcc-2.95.3-stlport-4.6.2-linux test_array_tricky: 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 intel-win32-9_0 vc-7_1 test_bind: 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 intel-win32-9_0 test_bind_tricky: 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 intel-win32-9_0 vc-7_1 test_complex: gcc-2.95.3-linux test_exception: gcc-2.95.3-stlport-4.6.2-linux test_function_tricky: 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 intel-win32-9_0 vc-7_1 test_functional: gcc-2.95.3-linux test_hash: gcc-2.95.3-linux test_mem_fn_tricky: 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 intel-win32-9_0 vc-7_1 test_memory: gcc-2.95.3-linux test_new: gcc-2.95.3-stlport-4.6.2-linux test_reference_wrapper_tricky: 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 intel-win32-9_0 vc-7_1 test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tuple_tricky: 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 intel-win32-9_0 vc-7_1 test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |tuple| tuple_test_bench: gcc-3_4_3-sunos |type_traits| tr1_add_const_test: gcc-2.95.3-linux tr1_add_cv_test: gcc-2.95.3-linux tr1_add_pointer_test: gcc-2.95.3-linux tr1_add_reference_test: gcc-2.95.3-linux tr1_add_volatile_test: gcc-2.95.3-linux tr1_aligned_storage_test: gcc-2.95.3-linux tr1_alignment_of_test: gcc-2.95.3-linux tr1_extent_test: gcc-2.95.3-linux tr1_has_nothrow_assign_test: gcc-2.95.3-linux tr1_has_nothrow_constr_test: gcc-2.95.3-linux tr1_has_nothrow_copy_test: gcc-2.95.3-linux tr1_has_trivial_assign_test: gcc-2.95.3-linux tr1_has_trivial_constr_test: gcc-2.95.3-linux tr1_has_trivial_copy_test: gcc-2.95.3-linux tr1_has_trivial_destructor_test: gcc-2.95.3-linux tr1_has_virtual_destructor_test: gcc-2.95.3-linux tr1_is_abstract_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin tr1_is_arithmetic_test: gcc-2.95.3-linux tr1_is_array_test: gcc-2.95.3-linux tr1_is_base_of_test: gcc-2.95.3-linux tr1_is_class_test: gcc-2.95.3-linux tr1_is_compound_test: gcc-2.95.3-linux tr1_is_const_test: gcc-2.95.3-linux tr1_is_convertible_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tr1_is_empty_test: gcc-2.95.3-linux tr1_is_enum_test: gcc-2.95.3-linux tr1_is_floating_point_test: gcc-2.95.3-linux tr1_is_function_test: gcc-2.95.3-linux tr1_is_fundamental_test: gcc-2.95.3-linux tr1_is_integral_test: gcc-2.95.3-linux tr1_is_member_func_test: gcc-2.95.3-linux tr1_is_member_obj_test: gcc-2.95.3-linux tr1_is_member_pointer_test: gcc-2.95.3-linux tr1_is_object_test: gcc-2.95.3-linux tr1_is_pod_test: gcc-2.95.3-linux tr1_is_pointer_test: gcc-2.95.3-linux tr1_is_polymorphic_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tr1_is_reference_test: gcc-2.95.3-linux tr1_is_same_test: gcc-2.95.3-linux tr1_is_scalar_test: gcc-2.95.3-linux tr1_is_signed_test: gcc-2.95.3-linux tr1_is_union_test: gcc-2.95.3-linux tr1_is_unsigned_test: gcc-2.95.3-linux tr1_is_void_test: gcc-2.95.3-linux tr1_is_volatile_test: gcc-2.95.3-linux tr1_rank_test: gcc-2.95.3-linux tr1_remove_all_extents_test: gcc-2.95.3-linux tr1_remove_const_test: gcc-2.95.3-linux tr1_remove_cv_test: gcc-2.95.3-linux tr1_remove_extent_test: gcc-2.95.3-linux tr1_remove_pointer_test: gcc-2.95.3-linux tr1_remove_reference_test: gcc-2.95.3-linux tr1_remove_volatile_test: gcc-2.95.3-linux |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 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 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 template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| test3u: gcc-3_3-darwin test4u: gcc-3_3-darwin test5u: gcc-3_3-darwin test6u: gcc-3_3-darwin test9u: gcc-3_3-darwin

1 0

[Boost-bugs] [ boost-Support Requests-1343952 ] object tracking
by SourceForge.net 31 Oct '05

31 Oct '05

Support Requests item #1343952, was opened at 2005-10-31 14:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1343952&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke (jla2w) Assigned to: Nobody/Anonymous (nobody) Summary: object tracking Initial Comment: I upgraded my compiler from VC7 to VC7.1. I rebuilt boost using the new compiler and rebuilt my application. No code relating to use of boost (I use it for it's serialization library) changed, and it worked in VC7, but now I get an assertion in the file oserializer.hpp BOOST_STATIC_ASSERT(check_tracking<T>::value) it says I need to check my object tracking settings...My question is why would it not do this for vc7.0, but it does this for VC7.1? What can I do to remedy this? I use default object tracking settings throughout and I do serialize through pointers a lot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1343952&group_… ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Support Requests-1343929 ] object tracking
by SourceForge.net 31 Oct '05

31 Oct '05

Support Requests item #1343929, was opened at 2005-10-31 14:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1343929&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke (jla2w) Assigned to: Nobody/Anonymous (nobody) Summary: object tracking Initial Comment: I upgraded my compiler from VC7 to VC7.1. I rebuilt boost using the new compiler and rebuilt my application. No code relating to use of boost (I use it for it's serialization library) changed, and it worked in VC7, but now I get an assertion in the file oserializer.hpp BOOST_STATIC_ASSERT(check_tracking<T>::value) it says I need to check my object tracking settings...My question is why would it not do this for vc7.0, but it does this for VC7.1? What can I do to remedy this? I use default object tracking settings throughout and I do serialize through pointers a lot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1343929&group_… ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[MPL.Math] big_integral and unsigned_big_integral
by Cromwell Enage 31 Oct '05

31 Oct '05

Once again, the latest offering is at <http://boost-consulting.com/vault/>, inside Template Metaprogramming. The ability to write constants like big_integral<positive_sign,1,0,4,8,5,7,6> has returned. In addition, you can also write a constant like unsigned_big_integral<1,0,4,8,5,7,6>, which is equivalent to the above. The two missing pieces wrt full functionality are division and human-readable output. The latter is easier to tackle but will most likely require a corresponding runtime big-integer class. Is anybody (e.g. Christopher Diggins) still working on one? If so, I might use it as a value_type. In a future version I'll probably get rid of positive_sign and negative_sign and just have the user specify '+' or '-'. Peder, I've made changes to the following files: * <boost/mpl/math/numerator.hpp> * <boost/mpl/math/denominator.hpp> * <boost/mpl/math/whole_part.hpp> * <boost/mpl/math/rational_part.hpp> * <boost/mpl/math/big_integral_tag.hpp> * <boost/mpl/math/big_integral_fwd.hpp> * everything in boost/mpl/math/big_integral_ and boost/mpl/math/big_integral_/aux_ * <boost/mpl/math/big_integral.hpp> * <boost/mpl/math/rational.hpp> * <boost/mpl/math/mixed_number.hpp> * <boost/mpl/math/complex_number.hpp> * examples/big_integral.cpp * test/big_integral.cpp Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 3

[mpl::math Rational] type member
by Andy Little 31 Oct '05

31 Oct '05

Hi Cromwell, in <boost/mpl/math/rational.hpp> In the definition for mpl::math::rational would it not be better to make the nested type member using the numerator and denominator rather than the input parameters.eg for: typedef rational<integral_c_<int,2>,integral_c<int,8> >::type type; currently type is a rational<integral_c_<int,2>,integral_c<int,8> > in the second case type is a rational<integral_c_<int,1>,integral_c<int,4> > I believe the second is superior. Can supply a patch if you like ... Secondly, are the next and prior members necessary? IMO they only make sense for integers. Thirdly, It should be noted that there is a <boost/mpl/math/rational_c.hpp> header, but as rational_c is defined in <boost/mpl/math/rational.hpp> I think its now both redundant and confusing. Cheers Andy Little

5 18

Binary files in CVS not marked as binary
by Peter Dimov 30 Oct '05

30 Oct '05

M libs/iostreams/doc/theme/boost_small.png M libs/program_options/test/ucs2.txt M libs/program_options/test/utf8.txt M libs/ptr_container/doc/cboost.gif -- Peter Dimov http://www.pdimov.com

1 0

Boost regression notification (2005-10-29 [RC_1_33_0])
by Douglas Gregor 30 Oct '05

30 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-29T15:30:18Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 11 failures in 4 libraries: date_time (1) parameter (1) range (3) serialization (6) |date_time| testtz_database: intel-win32-8_1 |parameter| tutorial: gcc-2.95.3-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin test_class_info_load_xml_archive: cw-9_5-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin test_demo_xml_load: intel-win32-8_1 test_shared_ptr_132_text_warchive: intel-win32-8_1

3 4