- Boost - lists.boost.org

[multi_index][ann][rfc] Preview of Boost.MultiIndex 1.34 release
by Joaquín Mª López Muñoz 18 Jan '06

18 Jan '06

It is a pleasure for me to announce the availability of a preview version of Boost.MultiIndex as planned for shipping with Boost 1.34, downloadable at the Vault: http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… (file multi_index.zip) This version includes several important new features: * New random access indices, which behave like sequenced indices with the added benefit of random access semantics. * Rearrange facilities in sequenced and random access indices, allowing for interoperability with external mutating algorithms. This is IMHO an important feature that can open up new usage scenarios for Boost.MultiIndex. * Several optimizations, of which the most important one relates to ordered indices headers, which are now 4 bytes shorter (on 32 bit systems): this optimization also leads to better performance for large numbers of elements. All in all, the upgrade is very extensive, so I'd appreciate if you test if for backwards compatibility even if you don't plan to use the new features. Additionally, I'd greatly welcome receiving any kind of feedback on the new stuff, the docs (which has been restructured and expanded) and whatever aspect you might think can be improved. I plan to commit this new version to the CVS in a couple of weeks or so, so if you have any comments please bring them here now! Thanks very much for your interest in the library, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Boost regression notification (2006-01-18 [HEAD])
by Douglas Gregor 18 Jan '06

18 Jan '06

Boost Regression test failures Report time: 2006-01-18T14:47:13Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 442 failures in 21 libraries xpressive (24) date_time (6) multi_array (2) python (13) graph (5) random (1) numeric/interval (3) signals (30) tr1 (3) concept_check (21) smart_ptr (2) rational (4) filesystem (31) test (5) program_options (7) serialization (206) wave (3) parameter (12) spirit (34) iostreams (22) typeof (8) |xpressive| c_traits: cw-9_5-darwin misc1: cw-9_5-darwin regress: cw-9_5-darwin test1: cw-9_5-darwin test10: cw-9_5-darwin test10u: cw-9_5-darwin test1u: cw-9_5-darwin test2: cw-9_5-darwin test2u: cw-9_5-darwin test3: cw-9_5-darwin test3u: cw-9_5-darwin test4: cw-9_5-darwin test4u: cw-9_5-darwin test5: cw-9_5-darwin test5u: cw-9_5-darwin test6: cw-9_5-darwin test6u: cw-9_5-darwin test7: cw-9_5-darwin test7u: cw-9_5-darwin test8: cw-9_5-darwin test8u: cw-9_5-darwin test9: cw-9_5-darwin test9u: cw-9_5-darwin test_non_char: cw-9_5-darwin |date_time| testgreg_serialize_dll: cw-9_4 intel-win32-8_1 intel-win32-9_0 vc-7_1 vc-7_1 vc-7_1 |multi_array| access: gcc-3.3.6-linux gcc-3.4.4-linux |python| defaults: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.5-linux gcc-4.0.2-linux docstring: cw-9_4 gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.5-linux gcc-4.0.2-linux numpy: gcc-4_0-darwin slice: gcc-4_0-darwin |graph| csr_graph_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux graphviz_test: vc-7_1 vc-7_1 vc-7_1 |random| random_test: intel-9.0-linux |numeric/interval| det: tru64cxx71-006 mul: tru64cxx71-006 overflow: tru64cxx71-006 |signals| dead_slot_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.5-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4.0.2-linux gcc-4_0-darwin mingw-3_4_2 mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 trackable_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.5-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4.0.2-linux gcc-4_0-darwin mingw-3_4_2 mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 |tr1| test_exception: gcc-2.95.3-stlport-4.6.2-linux test_new: gcc-2.95.3-stlport-4.6.2-linux test_stdexcept: gcc-2.95.3-stlport-4.6.2-linux |concept_check| stl_concept_covering: cw-9_4 cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.5-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4.0.2-linux gcc-4_0-darwin intel-9.0-linux intel-win32-8_1 intel-win32-9_0 mingw-3_4_2 mingw-3_4_2 tru64cxx71-006 vc-7_1 vc-7_1 vc-7_1 |smart_ptr| auto_ptr_rv_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |rational| rational_test: gcc-2.95.3-stlport-4.6.2-linux vc-7_1 vc-7_1 vc-7_1 |filesystem| convenience_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux fstream_test: gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux large_file_support_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mbcopy: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux mingw-3_4_2 mingw-3_4_2 mbpath: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 mingw-3_4_2 operations_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux operations_test_dll: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux path_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux path_test_dll: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux simple_ls: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux wide_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux mingw-3_4_2 mingw-3_4_2 tru64cxx71-006 |test| test_fp_comparisons: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tools_test: gcc-4_0-darwin mingw-3_4_2 mingw-3_4_2 |program_options| cmdline_test_dll: cw-9_4 options_description_test_dll: cw-9_4 parsers_test_dll: cw-9_4 positional_options_test_dll: cw-9_4 unicode_test_dll: cw-9_4 variable_map_test_dll: cw-9_4 winmain_dll: cw-9_4 |serialization| test_array_binary_archive_dll: cw-9_4 test_array_text_archive_dll: cw-9_4 test_array_text_warchive_dll: cw-9_4 test_array_xml_archive_dll: cw-9_4 test_array_xml_warchive_dll: cw-9_4 test_binary_binary_archive_dll: cw-9_4 test_binary_text_archive_dll: cw-9_4 test_binary_text_warchive_dll: cw-9_4 test_binary_xml_archive_dll: cw-9_4 test_binary_xml_warchive_dll: cw-9_4 test_class_info_load_binary_archive_dll: cw-9_4 test_class_info_load_text_archive_dll: cw-9_4 test_class_info_load_text_warchive_dll: cw-9_4 test_class_info_load_xml_archive_dll: cw-9_4 test_class_info_load_xml_warchive_dll: cw-9_4 test_class_info_save_binary_archive_dll: cw-9_4 test_class_info_save_text_archive_dll: cw-9_4 test_class_info_save_text_warchive_dll: cw-9_4 test_class_info_save_xml_archive_dll: cw-9_4 test_class_info_save_xml_warchive_dll: cw-9_4 test_contained_class_binary_archive_dll: cw-9_4 test_contained_class_text_archive_dll: cw-9_4 test_contained_class_text_warchive_dll: cw-9_4 test_contained_class_xml_archive_dll: cw-9_4 test_contained_class_xml_warchive_dll: cw-9_4 test_cyclic_ptrs_binary_archive_dll: cw-9_4 test_cyclic_ptrs_text_archive_dll: cw-9_4 test_cyclic_ptrs_text_warchive_dll: cw-9_4 test_cyclic_ptrs_xml_archive_dll: cw-9_4 test_cyclic_ptrs_xml_warchive_dll: cw-9_4 test_delete_pointer_binary_archive_dll: cw-9_4 test_delete_pointer_text_archive_dll: cw-9_4 test_delete_pointer_text_warchive_dll: cw-9_4 test_delete_pointer_xml_archive_dll: cw-9_4 test_delete_pointer_xml_warchive_dll: cw-9_4 test_demo_auto_ptr_dll: cw-9_4 test_demo_fast_archive_dll: cw-9_4 test_demo_pimpl_dll: cw-9_4 test_demo_polymorphic_dll: cw-9_4 test_demo_portable_archive_dll: cw-9_4 test_deque_binary_archive_dll: cw-9_4 test_deque_text_archive_dll: cw-9_4 test_deque_text_warchive_dll: cw-9_4 test_deque_xml_archive_dll: cw-9_4 test_deque_xml_warchive_dll: cw-9_4 test_derived_binary_archive_dll: cw-9_4 test_derived_class_binary_archive_dll: cw-9_4 test_derived_class_ptr_binary_archive_dll: cw-9_4 test_derived_class_ptr_text_archive_dll: cw-9_4 test_derived_class_ptr_text_warchive_dll: cw-9_4 test_derived_class_ptr_xml_archive_dll: cw-9_4 test_derived_class_ptr_xml_warchive_dll: cw-9_4 test_derived_class_text_archive_dll: cw-9_4 test_derived_class_text_warchive_dll: cw-9_4 test_derived_class_xml_archive_dll: cw-9_4 test_derived_class_xml_warchive_dll: cw-9_4 test_derived_text_archive_dll: cw-9_4 test_derived_text_warchive_dll: cw-9_4 test_derived_xml_archive_dll: cw-9_4 test_derived_xml_warchive_dll: cw-9_4 test_diamond_binary_archive_dll: cw-9_4 test_diamond_text_archive_dll: cw-9_4 test_diamond_text_warchive_dll: cw-9_4 test_diamond_xml_archive_dll: cw-9_4 test_diamond_xml_warchive_dll: cw-9_4 test_list_binary_archive_dll: cw-9_4 test_list_ptrs_binary_archive_dll: cw-9_4 test_list_ptrs_text_archive_dll: cw-9_4 test_list_ptrs_text_warchive_dll: cw-9_4 test_list_ptrs_xml_archive_dll: cw-9_4 test_list_ptrs_xml_warchive_dll: cw-9_4 test_list_text_archive_dll: cw-9_4 test_list_text_warchive_dll: cw-9_4 test_list_xml_archive_dll: cw-9_4 test_list_xml_warchive_dll: cw-9_4 test_map_binary_archive_dll: cw-9_4 test_map_text_archive_dll: cw-9_4 intel-win32-8_1 test_map_text_warchive: intel-win32-8_1 test_map_text_warchive_dll: cw-9_4 test_map_xml_archive_dll: cw-9_4 test_map_xml_warchive_dll: cw-9_4 test_multiple_ptrs_binary_archive_dll: cw-9_4 test_multiple_ptrs_text_archive_dll: cw-9_4 test_multiple_ptrs_text_warchive_dll: cw-9_4 test_multiple_ptrs_xml_archive_dll: cw-9_4 test_multiple_ptrs_xml_warchive_dll: cw-9_4 test_non_default_ctor_binary_archive_dll: cw-9_4 test_non_default_ctor_text_archive_dll: cw-9_4 test_non_default_ctor_text_warchive_dll: cw-9_4 test_non_default_ctor_xml_archive_dll: cw-9_4 test_non_default_ctor_xml_warchive_dll: cw-9_4 test_non_intrusive_binary_archive_dll: cw-9_4 test_non_intrusive_text_archive_dll: cw-9_4 test_non_intrusive_text_warchive_dll: cw-9_4 test_non_intrusive_xml_archive_dll: cw-9_4 test_non_intrusive_xml_warchive_dll: cw-9_4 test_null_ptr_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_null_ptr_binary_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux test_null_ptr_text_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_null_ptr_text_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux test_null_ptr_text_warchive: gcc-3.3.6-linux gcc-3.4.4-linux test_null_ptr_text_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux test_null_ptr_xml_archive_dll: cw-9_4 test_null_ptr_xml_warchive_dll: cw-9_4 test_nvp_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_nvp_binary_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux test_nvp_text_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_nvp_text_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux test_nvp_text_warchive: gcc-3.3.6-linux gcc-3.4.4-linux test_nvp_text_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux test_nvp_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_nvp_xml_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux test_nvp_xml_warchive: gcc-3.3.6-linux gcc-3.4.4-linux test_nvp_xml_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux test_object_binary_archive_dll: cw-9_4 test_object_text_archive_dll: cw-9_4 test_object_text_warchive_dll: cw-9_4 test_object_xml_archive_dll: cw-9_4 test_object_xml_warchive_dll: cw-9_4 test_optional_binary_archive_dll: cw-9_4 test_optional_text_archive_dll: cw-9_4 test_optional_text_warchive_dll: cw-9_4 test_optional_xml_archive_dll: cw-9_4 test_optional_xml_warchive_dll: cw-9_4 test_polymorphic_binary_archive_dll: cw-9_4 test_polymorphic_text_archive_dll: cw-9_4 test_polymorphic_text_warchive_dll: cw-9_4 test_polymorphic_xml_archive_dll: cw-9_4 test_polymorphic_xml_warchive_dll: cw-9_4 test_primitive_binary_archive_dll: cw-9_4 test_primitive_text_archive_dll: cw-9_4 test_primitive_text_warchive_dll: cw-9_4 test_primitive_xml_archive_dll: cw-9_4 test_primitive_xml_warchive_dll: cw-9_4 test_private_ctor_dll: cw-9_4 test_recursion_binary_archive_dll: cw-9_4 test_recursion_text_archive_dll: cw-9_4 test_recursion_text_warchive_dll: cw-9_4 test_recursion_xml_archive_dll: cw-9_4 test_recursion_xml_warchive: gcc-3.4.4-linux test_recursion_xml_warchive_dll: cw-9_4 gcc-3.3.6-linux test_reset_object_address_dll: cw-9_4 test_set_binary_archive_dll: cw-9_4 test_set_text_archive_dll: cw-9_4 test_set_text_warchive_dll: cw-9_4 test_set_xml_archive_dll: cw-9_4 test_set_xml_warchive_dll: cw-9_4 test_shared_ptr_132_text_archive: intel-win32-8_1 test_shared_ptr_132_text_archive_dll: intel-win32-8_1 test_simple_class_binary_archive_dll: cw-9_4 test_simple_class_ptr_binary_archive_dll: cw-9_4 test_simple_class_ptr_text_archive_dll: cw-9_4 test_simple_class_ptr_text_warchive_dll: cw-9_4 test_simple_class_ptr_xml_archive_dll: cw-9_4 test_simple_class_ptr_xml_warchive_dll: cw-9_4 test_simple_class_text_archive_dll: cw-9_4 test_simple_class_text_warchive_dll: cw-9_4 test_simple_class_xml_archive_dll: cw-9_4 test_simple_class_xml_warchive_dll: cw-9_4 test_split_binary_archive_dll: cw-9_4 test_split_text_archive_dll: cw-9_4 test_split_text_warchive_dll: cw-9_4 test_split_xml_archive_dll: cw-9_4 test_split_xml_warchive_dll: cw-9_4 test_tracking_binary_archive_dll: cw-9_4 test_tracking_text_archive_dll: cw-9_4 test_tracking_text_warchive_dll: cw-9_4 test_tracking_xml_archive_dll: cw-9_4 test_tracking_xml_warchive_dll: cw-9_4 test_variant_binary_archive_dll: cw-9_4 test_variant_text_archive_dll: cw-9_4 test_variant_text_warchive_dll: cw-9_4 test_variant_xml_archive_dll: cw-9_4 test_variant_xml_warchive_dll: cw-9_4 test_vector_binary_archive_dll: cw-9_4 test_vector_text_archive_dll: cw-9_4 test_vector_text_warchive_dll: cw-9_4 test_vector_xml_archive_dll: cw-9_4 test_vector_xml_warchive_dll: cw-9_4 test_void_cast_dll: cw-9_4 |wave| testwave: cw-9_5-darwin testwave_dll: cw-9_4 cw-9_5-darwin |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tutorial: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |spirit| scanner_value_type_tests: cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.5-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4.0.2-linux gcc-4_0-darwin intel-9.0-linux intel-win32-8_1 intel-win32-9_0 tru64cxx71-006 vc-7_1 vc-7_1 vc-7_1 scanner_value_type_tests_debug: cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.5-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4.0.2-linux gcc-4_0-darwin intel-9.0-linux intel-win32-8_1 intel-win32-9_0 tru64cxx71-006 vc-7_1 vc-7_1 vc-7_1 |iostreams| auto_close_test: tru64cxx71-006 code_converter_test: tru64cxx71-006 component_access_test: tru64cxx71-006 compose_test: tru64cxx71-006 copy_test: tru64cxx71-006 counter_test: tru64cxx71-006 example_test: tru64cxx71-006 filtering_stream_test: tru64cxx71-006 finite_state_filter_test: tru64cxx71-006 flush_test: tru64cxx71-006 invert_test: tru64cxx71-006 line_filter_test: tru64cxx71-006 newline_test: tru64cxx71-006 pipeline_test: tru64cxx71-006 regex_filter_test: tru64cxx71-006 restrict_test: tru64cxx71-006 seekable_file_test: tru64cxx71-006 seekable_filter_test: tru64cxx71-006 stdio_filter_test: tru64cxx71-006 symmetric_filter_test: tru64cxx71-006 tee_test: tru64cxx71-006 wide_stream_test: tru64cxx71-006 |typeof| function_ptr_from_tpl_emulation: vc-7_1 vc-7_1 vc-7_1 function_ptr_from_tpl_native: vc-7_1 vc-7_1 vc-7_1 lvalue_emulation: gcc-4.0.2-linux lvalue_native: gcc-4.0.2-linux

1 0

OT - option to strip lib off version on install
by Manfred Doudar 18 Jan '06

18 Jan '06

All: Sorry, slightly off-topic this time, but I know the last time I built the Boost libs, I specified an option to strip or rather create soft-links to versioned libraries, with soft-links stripping off version numbers (hope I'm clear); so that: libboost_date_time-1_31.so -> libboost_date_time.so libboost_date_time-gcc-mt-d-1_31.so -> libboost_date_time-mt.so Does any one of the top of their head know what that option is again? Cheers, -- Manfred Doudar - Research Engineer National ICT Australia (NICTA) Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA

3 2

Dave...
by Paul Mensonides 18 Jan '06

18 Jan '06

(Apologies to list members for this post.) Dave, I cannot reply to your off-list correspondence because your server (presumably) keeps bouncing my reply (see attachment). If you like, you can repost your comments to the list, and I can reply there. Regards, Paul Mensonides

1 0

[config][preprocessor] proposal for GCC-XML support
by Brad King 18 Jan '06

18 Jan '06

Hello, This message proposes adding GCC-XML support to the boost libraries to enable wrapping of more code with pyste. Most of the changes will probably be in the config and preprocessor libraries, but there may be others. Here is an explanation of the motivation and what needs to be done: Boost's Pyste tool http://www.boost.org/libs/python/pyste uses my tool GCC-XML http://www.gccxml.org to parse C++ code and then generates Boost.Python wrappers. Users have experienced problems getting some boost code to be parsed by GCC-XML. See the problem description http://www.gccxml.org/pipermail/gccxml/2006-January/000696.html and my explanation of what GCC-XML is doing http://www.gccxml.org/pipermail/gccxml/2006-January/000697.html for details. GCC-XML has two basic parts. One is a patched GCC compiler that has extra code to dump out an XML description of the interface found in a translation unit. The other is a front-end executable and some support code I wrote to enable GCC-XML to parse source code in a way that is compatible with wrapper generators. Wrapping arbitrary C++ code requires the wrapper generator to know about the standard library and implementation-defined types and interfaces provided by the compiler that will be used to build the generated code. In order to provide this information from the source GCC-XML simulates the preprocessing environment of a given compiler. This means that even though the parser is GCC the preprocessor definitions look like another compiler. For example, if msvc71 is specified as the compiler to simulate then the include path will be setup to use the system headers provided by Visual Studio .NET 2003. Preprocessor definitions such as _MSC_VER will be set they way they are when the native preprocessor runs. Unless a GCC compiler is being simulated, __GNUC__ is NOT defined. The only way for code to know that it is being preprocessed by GCC-XML is to look for the definition __GCCXML__. This macro is defined to be the GCC-XML version number (major*10000+minor*100+patchlevel). In a perfect world all compilers would be standard conforming and would all parse valid C++ code. In the real world there are inconsistencies and boost has many places that use compiler-specific parser work-arounds. Since GCC-XML uses a GCC parser but appears to the preprocessor as the native compiler special knowledge is needed when choosing implementation alternatives for compiler workarounds. GCC-XML is effectively another compiler for which knowledge should be encoded into the boost libraries. When __GCCXML__ is defined any *parser* work-around should use the GCC alternative, while any *interface* work-around should use the native compiler's alternative. For example, if a particular boost feature is not available on MSVC 6 then it should not be available if _MSC_VER=1200 even if __GCCXML__ is defined. On the other hand if the feature is always available but its implementation switches among different syntax choices to support multiple compilers then the GCC choice should be used if __GCCXML__ is defined. Therefore only parser work-arounds need to be updated with knowledge of GCC-XML. If choice of a specific GCC parser version is needed each GCC-XML version always uses a single GCC parser version (currently 3.3) so there is a simple mapping from the __GCCXML__ value to the GCC parser version number. The following are points for discussion: 1.) Is there interest in adding this support to enable both wrapping of more boost code and of more user code that uses boost with pyste? The motivating case mentioned above is trying to wrap serialization code which in turn uses mpl. 2.) What is the best way to encode knowledge of GCC-XML in boost libraries? I suspect most of the knowledge can be put in the config library when it defines macros encoding the availability of parser features. 3.) Does anyone volunteer to do the work? It can probably be done incrementally as users request support for wrapping of more boost code. I'm willing to help but I cannot spend very much time on this because it is really a boost/pyste problem and not a GCC-XML problem. -Brad

3 8

building of boost 1.33.1 - elf, serialization lib, and some misc warnings in thread & wave libs
by Manfred Doudar 18 Jan '06

18 Jan '06

All: There are some concerning (?) messages when building Boost Serialization, and other seemingly trivial warnings for Boost Threads, and Boost Wave that ought to be cleaned up. I apologize for the noise if this has been reported before, but I've been away from this NG for a while, given that I've moved house, and state, and job in the last few weeks. Miscellany: ---------- Building Boost 1.33.1 with gcc-3.3.5, on Debian 1:3.3.5-12, on a 2.6 Kernal. Being a luddite when it comes to the internals of elf formats, I get odd messages try to build Boost when it gets to the the Serialization Library - hopefully someone can interpret them for me: Boost.Serialization ------------------- gcc-C++-action bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/xml_oarchive.o gcc-Link-action bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/libboost_serialization-gcc-d-1_33_1.so /usr/bin/ld: `.L549' referenced in section `.rodata' of bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/basic_oarchive.o: defined in discarded section `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' of bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/basic_oarchive.o /usr/bin/ld: `.L559' referenced in section `.rodata' of bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/basic_oarchive.o: defined in discarded section `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' of bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/basic_oarchive.o Similarly for : basic_oarchive.o basic_text_iprimitive.o basic_text_oprimitive.o binary_iarchive.o binary_oarchive.o text_iarchive.o text_oarchive.o xml_grammar.o xml_iarchive.o xml_oarchive.o and the same (with some variation) for release paths: gcc-C++-action bin/boost/libs/serialization/build/libboost_wserialization.so/gcc/release/shared-linkable-true/threading-multi/xml_woarchive.o gcc-Link-action bin/boost/libs/serialization/build/libboost_wserialization.so/gcc/release/shared-linkable-true/threading-multi/libboost_wserialization-gcc-mt-1_33_1.so /usr/bin/ld: `.L1456' referenced in section `.rodata' of bin/boost/libs/serialization/build/libboost_wserialization.so/gcc/release/shared-linkable-true/threading-multi/basic_text_woprimitive.o: defined in discarded section `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' of bin/boost/libs/serialization/build/libboost_wserialization.so/gcc/release/shared-linkable-true/threading-multi/basic_text_woprimitive.o /usr/bin/ld: `.L1466' referenced in section `.rodata' of bin/boost/libs/serialization/build/libboost_wserialization.so/gcc/release/shared-linkable-true/threading-multi/basic_text_woprimitive.o: defined in discarded section `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' of bin/boost/libs/serialization/build/libboost_wserialization.so/gcc/release/shared-linkable-true/threading-multi/basic_text_woprimitive.o /usr/bin/ld: `.L1457' referenced in section `.rodata' of bin/boost/libs/serialization/build/libboost_wserialization.so/gcc/release/shared-linkable-true/threading-multi/basic_text_woprimitive.o: defined in discarded section `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' of bin/boost/libs/serialization/build/libboost_wserialization.so/gcc/release/shared-linkable-true/threading-multi/basic_text_woprimitive.o ... you get the idea. All I can fathom is that some symbols are referenced in read-only-data sections - that aren't ever going to be read. Building with gcc-3.3.5, on Debian 1:3.3.5-12, on a 2.6 Kernal. Any ideas as to why I get the above would be appreciated - I know Robert went to great lengths to ensure backward compatibility with older compilers for the Serialization lib, so I'm guessing it's some issue with my current system setup, who knows ? That aside, there's a warning that might otherwise be cleaned up (if not already done so), about unused variables: Boost.Threads: -------------- /home/users/manfredd/MyDownloads/boost_1_33_1/libs/thread/src/recursive_mutex.cpp: In member function `boost::recursive_mutex::recursive_mutex()': /home/users/manfredd/MyDownloads/boost_1_33_1/libs/thread/src/recursive_mutex.cpp:299: warning: unused variable `int res' /home/users/manfredd/MyDownloads/boost_1_33_1/libs/thread/src/recursive_mutex.cpp: In member function `boost::recursive_try_mutex::recursive_try_mutex()': /home/users/manfredd/MyDownloads/boost_1_33_1/libs/thread/src/recursive_mutex.cpp:455: warning: unused variable `int res' Boost.Wave ---------- gcc-C++-action bin/boost/libs/wave/build/libboost_wave.a/gcc/release/cpp_re.o cpp.re: In function `boost::wave::token_id boost::wave::cpplexer::re2clex::scan(boost::wave::cpplexer::re2clex::Scanner*) ': cpp_re.cpp:407: warning: `unsigned int yyaccept' might be used uninitialized in this function Thanks in advance, -- Manfred Doudar - Research Engineer National ICT Australia (NICTA) Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA

2 1

Windows event objects still considered harmful?
by Robin Boerdijk 18 Jan '06

18 Jan '06

Hi, I don't agree with the rationale for excluding a Windows event object-like construct from the Boost thread package. The rationale justifies the exclusion based on the "Concurrent Programming Concepts" paper by Per Brich Hansen in which event variables are dismissed as unsafe. The fundamental problem of event variables according to Hansen's paper is that, "if the sender causes [signals] the event before the receiver waits for it, the receiver will remain delayed until the next event is caused [signalled]". However, Windows event objects don't work like this. From the API specification: "When the state of an auto-reset event object is signaled, it remains signaled until a single waiting thread is released; the system then automatically resets the state to nonsignaled. If no threads are waiting, the event object's state remains signaled." In other words, the receiver will _not_ remain delayed if the sender signals the event before the receiver waits for it. Based on this observation, I think the reference to Hansen's paper should be removed from the rationale. It does not apply to Windows event objects and I had to spend $10 to download the paper from the ACM website and find this out. Furthermore, according to the rationale, "Experienced programmers using the Windows platform today report that event variables are a continuing source of errors". Are there any links to documents that describe these problems? Are these problems perhaps related to the PulseEvent() method, which does cause the behaviour Hansen described but has been deprecated (the API documentation states "This function is unreliable and should not be used. It exists mainly for backward compatibility"). In short, are Windows event objects still considered harmful? Thanks, Robin Boerdijk __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 2

Windows event objects still considered harmful?
by Robin Boerdijk 18 Jan '06

18 Jan '06

Hi, I don't agree with the rationale for excluding a Windows event object-like construct from the Boost thread package. The rationale justifies the exclusion based on the "Concurrent Programming Concepts" paper by Per Brich Hansen in which event variables are dismissed as unsafe. The fundamental problem of event variables according to Hansen's paper is that, "if the sender causes [signals] the event before the receiver waits for it, the receiver will remain delayed until the next event is caused [signalled]". However, Windows event objects don't work like this. From the API specification: "When the state of an auto-reset event object is signaled, it remains signaled until a single waiting thread is released; the system then automatically resets the state to nonsignaled. If no threads are waiting, the event object's state remains signaled." In other words, the receiver will _not_ remain delayed if the sender signals the event before the receiver waits for it. Based on this observation, I think the reference to Hansen's paper should be removed from the rationale. It does not apply to Windows event objects and I had to spend $10 to download the paper from the ACM website and find this out. Furthermore, according to the rationale, "Experienced programmers using the Windows platform today report that event variables are a continuing source of errors". Are there any links to documents that describe these problems? Are these problems perhaps related to the PulseEvent() method, which does cause the behaviour Hansen described but has been deprecated (the API documentation states "This function is unreliable and should not be used. It exists mainly for backward compatibility"). In short, are Windows event objects still considered harmful? Thanks, Robin Boerdijk __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

[doc,patch] iterator_facade.html
by LI Daobing 18 Jan '06

18 Jan '06

$ diff -u /usr/share/doc/libboost-doc/HTML/libs/iterator/doc/it erator_facade.html iterator_facade.html --- /usr/share/doc/libboost-doc/HTML/libs/iterator/doc/iterator_facade.html 2006-01-12 00:23:36.000000000 +0800 +++ iterator_facade.html 2006-01-18 14:46:22.000000000 +0800 @@ -1110,7 +1110,7 @@ <pre class="literal-block"> class const_node_iterator : public boost::iterator_facade< - node_iterator + const_node_iterator , node_base <strong>const</strong> , boost::forward_traversal_tag > -- LI Daobing

1 0

Pointer variant
by Pierre THIERRY 18 Jan '06

18 Jan '06

In my code, I use variants with only pointers type as bounded types. Mainly a plain pointer to a type and one or more smart pointers to this same type. Would a derived variant that would be dereferencable if all of it's bounded type also are of interest for Boost.Variant library? Would anyone be willing to implement it? (i.e. should I dive in the code and try to do it myself?) Variantly, Nowhere man -- nowhere.man(a)levallois.eu.org OpenPGP 0xD9D50D8A

1 0