- Boost - lists.preview.boost.org

[cstdint] uintptr_t and intptr_t are missing
by Maxim Yegorushkin 26 Sep '05

26 Sep '05

Is this intentional that uintptr_t and intptr_t types are missing in cstdint.hpp? If it is so, why? http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html

3 4

[math] Proposed TR1 additions
by John Maddock 26 Sep '05

26 Sep '05

Those of a mathematical inclination, might be interested to note that the only substantive code in the TR1 submission currently under review is some proposed additions to Boost.Math: mainly the inverse complex number trig functions. Just a heads up in case the "TR1" moniker didn't get your attention. John.

2 2

[mpl] The concept of laziness
by Cromwell Enage 26 Sep '05

26 Sep '05

I remember a thread that ran for a while on this topic, and I need to make sure I've wrapped my head around it correctly. Here are my takes on laziness: <take id="point-1"> A metafunction returns lazily if it can be used interchangeably with its return type. Numeric metatypes such as integral_c are examples of metafunctions that return lazily, e.g. "int_<6>" is the same as "typename int_<6>::type". Metafunctions such as next/prior, however, do not return lazily because they cannot be used interchangeably with their return types. For example, "times<next<int_<4> >,prior<long_<8> > >" is illegal; the expression must be "times<typename next<int_<4> >::type,typename prior<long_<8> >::type>". </take> <take id="point-2"> A metafunction evaluates a certain template argument lazily if it does not require the argument to be a fully instantiated type; otherwise, the evaluation is strict. The eval_if metafunction will strictly evaluate the second argument if the first argument is equivalent to false_; otherwise, it will strictly evaluate the third argument. </take> I'm less sure about point-2 than I am about point-1. In any case, feel free to correct any knowledge deficiencies I've exhibited, to make these definitions more complete. More examples would also be a great help. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

bug report for bjam 3.1.11
by Lewis Hyatt 26 Sep '05

26 Sep '05

Hi All, I apologize if this has been reported before, but I couldn't find it after a long search. I encountered problems building bjam on a standard Linux distribution (uname -a: Linux 2.4.21-32.0.1.EL #1 Wed May 25 14:34:59 EDT 2005 i686 i686 i386 GNU/Linux) with gcc. (same problem with gcc 3.2.2 or 4.0.1). The executable seg faulted every time. I tracked it to the function var_defines() in variable.c which had a logic error at lines 124-130. I didn't investigate far enough to determine why the function was receiving strings consisting of a single quote, and I do not know if this is irregular or not, but in any case the attached patch (output from diff -c) corrects the issue. -Lewis *** boost-jam-3.1.11/variable.c 2005-05-29 23:42:38.000000000 -0400 --- variable.c 2005-09-25 22:27:31.000000000 -0400 *************** *** 121,127 **** # endif size_t len = strlen(val + 1); ! int quoted = val[1] == '"' && val[len] == '"'; if ( quoted && preprocess ) { --- 121,127 ---- # endif size_t len = strlen(val + 1); ! int quoted = val[1] == '"' && val[len] == '"' && len>1; if ( quoted && preprocess ) {

2 1

Review Xpressive
by Tom Brinkman 26 Sep '05

26 Sep '05

*What is your evaluation of the design? Very good. * What is your evaluation of the implementation? Also, very good. * What is your evaluation of the documentation? I thought the documentation was comparable in quality to the best documented libraries in boost. * What is your evaluation of the potential usefulness of the library? As others have indicated, there is some overlap with other boost libraries. However, the emphasis of xpressive is different and somewhat more flexible. * Did you try to use the library? With what compiler? Did you have any problems? GCC 3.2. No problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've incorporated xpressive into a couple of small console applications. At first, I spent maybe 2 hours reading the documents and probably one hour to implement an xpressive solution. Since that time, I have read the documentation for an additional couple hours for more background. * Are you knowledgeable about the problem domain? Yes. As a user of boost::regex and boost::spirit. * Do you think the library should be accepted as a Boost library? Yes, without reservation. Tom Brinkman

4 4

uncreatable
by Jason Hise 26 Sep '05

26 Sep '05

Why does the following compile? The parameter type of A's pure virtual function is private. How come B can see it, allowing it to override the pure virtual function? class A { private: struct S { }; virtual void bar ( S ) = 0; }; class B : public A { public: virtual void bar ( A::S ) { } }; int main ( ) { B b; return 0; } -Jason

2 2

[mpl][math] double accuracy
by Peder Holt 25 Sep '05

25 Sep '05

What should we do about the accuracy of double_ operations? The implementation of plus,minus,times and divide mimics the behaviour of the runtime equivalent, double. This means that the mantissa is trunkated from 61 to 52 bit for every fundamental operation. The result of this, is that complex functions such as sine and exponential will differ from their runtime counterpart, unless a specialization is made for double_. The problem would disappear if we allow calculations with double_ to be more accurate than calculations with double. Is this a problem? Regards Peder

4 5

[typeof] native support in intel and como
by Arkadiy Vertleyb 25 Sep '05

25 Sep '05

Can anybody familiar with these compilers explain what needs to be done in order to be able to use the "typeof" keyword with them? From looking on the web, I got the impression that they have to support it, but my attempts to setup the tests fail with "typeof" undefined (I tried __typeof__ before this). Thanks, Arkadiy

3 2

[1.33.1][iostreams] Timetable and patches
by Jonathan Turkanis 25 Sep '05

25 Sep '05

Hi All, Do we have any timetable for 1.33.1? Will Bryant just pointed out a memory leak in Iostreams, and I'd like to post an Iostreams patch if 1.33.1 will not be ready reasonably soon. One more thing: before there was talk of 1.33.1, I prepared a patch for 1.33 to fix some minor stuff, but had trouble generating a single patch that worked for all the sourceforge 1.33 archives. Should it be necessary to post several patches, or was I doing something wrong? -- Jonathan Turkanis www.kangaroologic.com

3 7

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

25 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-25T15:24:07Z 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… 77 failures in 6 libraries: foreach (1) graph (5) iostreams (11) random (1) range (3) serialization (56) |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |iostreams| gzip_test: cw-9_5-darwin 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_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux vc-7_1 |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_contained_class_xml_archive: gcc-3.2.3-linux test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5

1 0

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

25 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-25T05:00:13Z 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 Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 176 failures in 14 libraries: concept_check (14) filesystem (8) foreach (7) graph (7) math (3) mpl (2) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (46) wave (4) |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 msvc vc-7_1 vc-7_1 |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| astar_search_test: vc-7_1 biconnected_components_test: vc-7_1 cuthill_mckee_ordering: vc-7_1 graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: 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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc 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| static_mutex_test: msvc |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: cw-9_4 data_member_native: intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 function_native: intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 function_ptr_native: intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 function_ref_native: intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 lvalue_native: intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 member_function_native: intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 noncopyable_native: intel-win32-9_0 std_native: intel-win32-9_0 template_dependent_native: intel-win32-9_0 template_enum_native: intel-win32-9_0 template_int_emulation: cw-9_4 template_int_native: intel-win32-9_0 intel-win32-9_0 template_multiword_native: intel-win32-9_0 template_tpl_emulation: cw-9_4 template_tpl_native: intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 template_type_native: intel-win32-9_0 intel-win32-9_0 type_emulation: cw-8_3 cw-9_4 cw-9_4 type_native: 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 intel-9.0-linux

1 0

[serialization] Archive implementation
by Matthias Troyer 25 Sep '05

25 Sep '05

Hi Robert, After tracking down a linker error I realized that #include <boost/archive/impl/archive_pointer_oserializer.ipp> #include <boost/archive/impl/archive_pointer_iserializer.ipp> need to be included for all new archives that a user might develop, in order to allow serialization of pointers. Are there other such *.ipp files that an archive developer needs to watch out for? Matthias

1 0

integer_mask for long long
by Aschwin Gopalan 25 Sep '05

25 Sep '05

Hi boosters, I am trying to do a small template based fixed-point arithmetic library and I am using integer_mask.hpp to extract some bit-masks I need. Everything works as expected as long as my fixed-point numbers are not larger than 32bit. I am on Intel hardware using gcc and there is long long, wich is 64bit. I would like to be able to use it together with my fixed point template, but integer_mask.hpp works only up to long. Is there a compelling reason for this? Greetings, Aki

2 2

Re: [boost] xml parser
by mario contestabile 25 Sep '05

25 Sep '05

Anyone have/know of boost samples of simple xml parsing (name-values)? thanx

2 1

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

24 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-24T14:56: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… 74 failures in 6 libraries: foreach (1) graph (5) random (1) range (3) serialization (56) thread (8) |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_contained_class_xml_archive: gcc-3.2.3-linux test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux

1 0

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

24 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-24T05:00:09Z 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. utility/enable_if typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 185 failures in 16 libraries: concept_check (14) filesystem (8) foreach (7) graph (4) math (3) mpl (2) numeric/ublas (1) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (41) utility/enable_if (16) wave (4) |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 msvc vc-7_1 vc-7_1 |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |numeric/ublas| concepts: vc-7_1 |parameter| basics: borland-5_6_4 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 msvc 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| static_mutex_test: msvc |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: cw-9_4 data_member_native: intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 function_native: intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 function_ptr_native: intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 function_ref_native: intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 lvalue_native: intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 member_function_native: intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 template_int_native: intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 template_tpl_native: intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 template_type_native: intel-win32-9_0 intel-win32-9_0 type_emulation: cw-8_3 cw-9_4 cw-9_4 type_native: intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 |utility/enable_if| constructors: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dummy_arg_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_templates: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux namespace_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux no_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux partial_specializations: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

1 0

[xpressive] formal review
by John Maddock 24 Sep '05

24 Sep '05

Finally, too late for even the extended deadline, here's my xpressive review: *What is your evaluation of the design? It's very good. I have to admit that I find the static regexes very hard to read, but a lot of that will be a cultural problem: I'm so used to seeing normal regex syntax that I can't quite get my head around the static versions, the quantifiers as prefixes particularly throw me. However, the syntax is concise and consistent with spirit, so I can hardly complain that much. Possibly xpressive isn't the last word on this, or the best way to go, personally I prefer more verbose forms like repeat(x) rather than *x but again, that's an initial reaction which may change with more familiarity. * What is your evaluation of the implementation? Looks good to me, and I know from past experience that Eric knows what he's doing. The only complaint I have is one that's common to all expression template code: it's impossible to understand by debugging, which means casual maintenance by folks other than the author would be hard, you really need to read the whole source before you can get a grip on what it's doing (OK you ought to do that anyway, but it is still hard to understand code that isn't executed in the traditional sense). As I said though this is an issue with all metaprogramming, and expression templates in particular, I guess what we really need is a compile-process debugger :-) * What is your evaluation of the documentation? It's excellent. * What is your evaluation of the potential usefulness of the library? Clearly there are lots of uses. There is also overlap with Regex and Spirit, but I don't believe that should prevent acceptance, Boost is meant to drive forward innovation after all. * Did you try to use the library? With what compiler? Did you have any problems? Not for as long as I would have liked :-( I've only tried with VC7.1, the sample code compiled cleanly, but compile times were quite long for even simple static regexes, I didn't try anything complex. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A couple hours reading the docs, and playing with some of the samples. One thing I did notice is that several of the test programs don't appear to do anything except "return 0", I'm not sure if these are deprecated, or just not finished (see test_regex_token_iterator.cpp for example). The test cases in the testX.cpp files may be a little short on the ground as well: Boost.Regex has about a thousand cases, PCRE a similar number, where as there are 171 here. The smaller number of cases ought to be enough, but in practice I've found you can never have too many! It's a pity that the Boost.Regex and / or PCRE cases can't be automatically harvested, but I suspect this is next to impossible for static regexes? * Are you knowledgeable about the problem domain? I hope so :-) * Do you think the library should be accepted as a Boost library? Absolutely. John.

2 1

[preprocessor] Proposal to add a unique names generating macro
by Andrey Semashev 24 Sep '05

24 Sep '05

I have mentioned this in a nearby thread about scope_guard, but I believe it missed the addresee. I purpose to add a macro to Boost.PP that will expand to some unique in translation unit scope name. I needed such functionality to generate unique variable names for anonymous scope guards, but I believe there are places in Boost that reimplement similar functionality (BOOST_STATIC_ASSERT does the same, from the top of my head). My implementation example is availeble in: http://boost-consulting.com/vault/index.php?action=downloadfile&filename=sc… See the file boost/guard/unique_name.hpp, BOOST_SG_UNIQUE_NAME macro. PS: I don't actually insist on Boost.PP to be the place for such macro, but I think it should be in some common place and be available to end users.

1 0

Re: [boost] BOOST_ASSERT and __assume
by brangdon＠cix.compulink.co.uk 24 Sep '05

24 Sep '05

In-Reply-To: <dh1gjf$bt0$1(a)sea.gmane.org> kalita(a)poczta.onet.pl (Marcin Kalicinski) wrote (abridged): > On the other hand some people (including me) consider __assume to be > nice, helping optimization and suppressing annoying warnings. Including me, too. I don't think anyone has spoken against __assume in principle. The issue has been how best to incorporate it. > Put __assume in BOOST_ASSUME and leave BOOST_ASSERT unmodified. This to me is the safest option. > Pros: > - does not disturb existing code in any way > > Cons: > - no existing code uses it, i.e. all existing libraries would have to > be modified to take advantage of it; this will probably never happen so > most of the code will not benefit __assume is a performance optimisation. As such I think it is fine for it to be adopted primarily in places where someone has seen the need (and in new code). It doesn't need to be adopted in /all/ libraries. If no-one thinks __assume is valuable enough to be worth changing old code to use it, perhaps it is not worth adding to boost at all. Is it entirely a Microsoft thing, or would some other compilers benefit too? > - obscure: most of the people would be confused about it when seeing it > for the first time Surely no more so than any other boost library? I'd have thought it would be even more confusing if BOOST_ASSERT changed its meaning. At least the people who don't know what ASSUME means know they don't know, and can look it up. A change to ASSERT will slip under many people's guard. BOOST_ASSERT and BOOST_ASSUME have different semantics. I think it's good to let authors express which semantics they intended. > 2. BOOST_ASSERT + define to enable assume (default: on) > Cons: > > - breaks user code which uses BOOST_ASSERT in "uncommon" way. And boost code as well. Probably there is no such code in boost, but I don't think anyone has gone through it all to check. Perhaps no user code would be broken either. To me this really feels like a gambler's option. Silently breaking users code is unacceptable, but maybe we are feeling lucky tonight. Or maybe we just don't care, and can rule such code unsupported. > BOOST_ASSERT + define to enable assume (default: off) > - does enable assume on all the boost code, some user programs get > smaller and faster with a simple -D"BOOST_ASSERT_USE_ASSUME" on command > line. In order to switch it on safely they need to know that every use of BOOST_ASSERT in every module they link, and every header they #include, is safe with the new semantics. I don't see how they can know this without laboriously checking every place where BOOST_ASSERT is used and thinking hard about the semantics of each one. This has to be repeated for every new release of the libraries. It's a ton of work, repeated once for each user. To me it makes far more sense for the work to be done once by the author of the code that uses the assert, and for the result of that analysis to be recorded in the code for all time by renaming from BOOST_ASSERT to BOOST_ASSUME. This will also help anyone reading the code. Another drawback of the global flag is that if just one place turns out to require the old semantics, no other places can use the new semantics. The whole app suffers. (It'd be tempted to define BOOST_ASSERT_USE_ASSUME for some modules and not others, but that leads to violation of the One Definition Rule.) In practice I think this option is the same as the previous one. Both are saying the "uncommon" uses are not supported any more. Certainly they can't be used within any library code, because the author doesn't know what options the user will compile it with. I don't think we want to double the testing burden by testing both with and without -D"BOOST_ASSERT_USE_ASSUME". The effect of -D"BOOST_ASSERT_USE_ASSUME" is to inject undefined behaviour into the code. To me that is huge. It's not a minor change of semantics. -- Dave Harris, Nottingham, UK.

1 0

[scope_guard] Naming roundup
by Andrey Semashev 24 Sep '05

24 Sep '05

So, there was a really interesting and hot discussion about namings. Many opinions were expressed and I'd like to make some roundup. These are the variants looked most suitable to me as the names of status modification functions: - arm/disarm. Although, noone have said anything about them, they are still in the current implementation and look quite applicable. - activate/deactivate (enable/disable). Other synonims for arm/disarm, a bit longer though. - on/off. The most laconic form. Though, these are not verbs as usually used for functions. One might think they are some getter functions. - guard/dismiss. On the on hand, the commonly used "dismiss" should look familiar. On the other, its meaning is too strong in regard of the function semantic. The "guard" may be used as well but the word is already frequently used. Besides, the guard's status enum values' names propably won't corellate with these words (I just don't see the active status name with root "guard" - guard::guarding? :( ). The other versions looked less reflective to me so I didn't include them in the list. I would be glad if you just vote for one of these positions to take the final decision. The make_guarded_call function name seems does not attract that much attention, so I shall leave it be. Besides, it it possible that I even remove it from the library, because it can be easily replaced by explicit "do" functor call and make_guard followed by it. Unfortunately, nearly no attention have been paid to the implementation itself, so there's nothing much to roundup here. PS: Still the question about checking in the library is arisen. The naming changes are 5 minutes worth, so the final version will be available very soon with almost no code changes. Will someone want to make a code revision or may I just gain access and checkin?

5 13

[serialization] boost::tuple
by troy d. straszheim 24 Sep '05

24 Sep '05

Serialization of tuple. This will come in handy when revamping serialization tests... http://svn.resophonic.com/pub/boost/boost/serialization/tuple.hpp http://svn.resophonic.com/pub/boost/libs/serialization/test/test_tuple.cpp -t

7 8

[Test] passed assertion count off by 1
by Kim Barrett 24 Sep '05

24 Sep '05

Using Boost.Test from the boost 1.33 release, The reported number of passed assertions for each test case is one greater than the actual number of assertions performed by the test case. For example, the most trivial of auto-unit-test programs, attached below, reports 1 assertion out of 1 passed. I see no test assertions here. ---------- #define BOOST_AUTO_TEST_MAIN #include <boost/test/unit_test.hpp> #include <boost/test/auto_unit_test.hpp> BOOST_AUTO_UNIT_TEST(test_no_assertions) { }

2 1

BOOST_ASSERT and __assume
by Marcin Kalicinski 23 Sep '05

23 Sep '05

Hi Everybody, I see there are mixed opinions on use of __assume in BOOST_ASSERT. The chief concern is there are people using BOOST_ASSERT in "uncommon" (but still valid) ways, such as: - to show dialog box, but only in debug mode - using assert handler to throw during unit testing - possibly more These types of usage would be prohibited if we introduced __assume into BOOST_ASSERT, so basically this is a no-no from stability point of view (nobody wants his code broken). Btw. the second way can be dealt with with disabling __assume if assertion handler is defined. On the other hand some people (including me) consider __assume to be nice, helping optimization and suppressing annoying warnings. I see 3 options: 1. BOOST_ASSUME =============================================== Put __assume in BOOST_ASSUME and leave BOOST_ASSERT unmodified. Pros: - does not disturb existing code in any way Cons: - no existing code uses it, i.e. all existing libraries would have to be modified to take advantage of it; this will probably never happen so most of the code will not benefit - obscure: most of the people would be confused about it when seeing it for the first time 2. BOOST_ASSERT + define to enable assume (default: on) =============================================== Pros: - does enable assume on all the boost code, some user programs get somewhat smaller and faster without any intervention from the programmer Cons: - breaks user code which uses BOOST_ASSERT in "uncommon" way. Would require a change in docs that executing BOOST_ASSERT(false) is undefined behavior (i.e. different than std::assert) BOOST_ASSERT + define to enable assume (default: off) =============================================== Pros: - does enable assume on all the boost code, some user programs get smaller and faster with a simple -D"BOOST_ASSERT_USE_ASSUME" on command line. Cons: - only small number of users will know about that #define, so probably most of the code will not benefit. What do you think? Marcin

4 3

Patch to boost/detail/interlocked.hpp
by Anthony Williams 23 Sep '05

23 Sep '05

I am trying to change my call_once implementation for boost.thread, so it doesn't require windows.h to be included. In doing so, I tried to use boost/detail/interlocked.hpp, and discovered that it doesn't work on gcc-mingw-4.0.1, since the imported functions are declared in boost::detail namespace, and the macros don't qualify the names. Attached is a patch for the file that changes the macros to refer to the imported functions by fully qualified names. Please can someone check and commit this for me. Anthony -- Anthony Williams Software Developer

2 4

Re: [boost] [scope_guard] New revision available + naming consideration
by Jason Stewart 23 Sep '05

23 Sep '05

I sent this earlier but it never showed up on the list. > > By the way, that might work well for smart > > pointers; why don't shared_ptr and friends use this idiom? > >Maybe because it allows more than a literal zero? I personally like the guard/dismiss names, they are reminiscent of commands you would give a real guard. However, maybe using the shared_ptr semantics would work. I.e. if you can create a guard that is "uninitialized" and then reset it later to an active guard. { scope_guard g; if (some condition) { g = scope_guard(my_undo_function); // do something here } if (some other condition) { // we changed our mind, dismiss it. g = scope_guard; // or ... // g.dismiss(); // g.reset(); // like shared_ptr } } It seems to me that is as easy to read as having an explicit "guard" or "activate" command is. I confess though that I didn't follow the early discussion closely so I apologize is this has been discussed already. Jason Stewart

4 6

[Boost-bugs] [ boost-Support Requests-1301634 ] Serialization lib missing
by SourceForge.net 23 Sep '05

23 Sep '05

Support Requests item #1301634, was opened at 2005-09-23 10: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=1301634&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Serialization lib missing Initial Comment: my email is jla2w(a)yahoo.com I am building the boost library and am specifically interested in serialization. When I follow the steps, I can't get the bjam.exe to recognize the version of spirit that would enable xml serialization. I did the following set SPIRIT_ROOT=C:/Documents and Settings/Luke/Desktop/spirit-1.6.3/boost as well as a couple other variants (not including the last boost) because it isn't clear to me which directory depth it needs to be..anyway, I get errors building the serialization libs (all others build correctly) with messages that choke on the xml files and then many that say that fatal error: Compiler not supported, check config.hpp this is presumably related to spirit env variable not being recognized. The other errors say that the libs were skipped for lack of other libs. One example is ...libboost_serialization-vc7-sgd.lib skipped for lack of libboost_serialization-vc7-sgd-1_33.lib Any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1301634&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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

23 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-23T14:27:13Z 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. utility/enable_if Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 75 failures in 7 libraries: foreach (1) graph (5) random (1) range (3) serialization (56) thread (8) utility/enable_if (1) |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_contained_class_xml_archive: gcc-3.2.3-linux test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |utility/enable_if| no_disambiguation: gcc-3.2.3-linux

1 0

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

23 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-23T05:00:15Z 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. utility/enable_if typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 189 failures in 15 libraries: concept_check (14) filesystem (8) foreach (7) graph (4) math (3) mpl (7) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (41) utility/enable_if (16) wave (4) |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 msvc vc-7_1 vc-7_1 |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| back: vc-7_1 count_if: vc-7_1 deque: vc-7_1 distance: vc-7_1 erase_range: vc-7_1 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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc 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| static_mutex_test: msvc |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: cw-9_4 data_member_native: intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 function_native: intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 function_ptr_native: intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 function_ref_native: intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 lvalue_native: intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 member_function_native: intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 template_int_native: intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 template_tpl_native: intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 template_type_native: intel-win32-9_0 intel-win32-9_0 type_emulation: cw-8_3 cw-9_4 cw-9_4 type_native: intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 |utility/enable_if| constructors: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dummy_arg_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_templates: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux namespace_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux no_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux partial_specializations: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

1 0

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

23 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-22T05:00:09Z 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. utility/enable_if typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 184 failures in 15 libraries: concept_check (14) filesystem (8) foreach (7) graph (4) math (3) mpl (2) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (41) utility/enable_if (16) wave (4) |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 msvc vc-7_1 vc-7_1 |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: 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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc 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| static_mutex_test: msvc |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: cw-9_4 data_member_native: intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 function_native: intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 function_ptr_native: intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 function_ref_native: intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 lvalue_native: intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 member_function_native: intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 template_int_native: intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 template_tpl_native: intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 template_type_native: intel-win32-9_0 intel-win32-9_0 type_emulation: cw-8_3 cw-9_4 cw-9_4 type_native: intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 |utility/enable_if| constructors: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dummy_arg_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_templates: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux namespace_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux no_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux partial_specializations: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

4 3

Re: [boost] [scope_guard] New revisionavailable + namingconsideration
by Greer, Joe 23 Sep '05

23 Sep '05

> Rob Stewart wrote: > > "Secure" is another choice. > Secure brings up images of encryption to me. Activate/Deactivate pair well as do a simple on/off as was also mentioned. joe

1 0

Re: [boost] Errors compiling multi_index hashed.cpp
by Joaquín Mª López Muñoz 23 Sep '05

23 Sep '05

David Crayford ha escrito: > Thanks Joaquin, actually the z/OS release is 6. I t= ried changing > __IBMCPP__ to 600 but it screwed the compile. OK. Well, the following is a slightly more convoluted way to check whether your compiler is able to cope with Boost, more or less: 1. Globally search "__IBMCPP__" in the codebase (about 100 occurrences) and replace it with, say, BOOST_IBMCPP. This task should be simple if you're a Unix man. 2. Compile your test code with a compiler switch defining the macro BOOST_IBMCPP to 600. I think in your case the compiler switch is -DBOOST_IBMCPP=600 3. Shake and serve. Please report your results back. Thank you! > I'm new to this list, how do I contact J= ohn Maddock? He's a regular on this list. If you post a message with a more focused subject line surely he'll delve in. > BTW, I'm sorry if my mails are mang= led, it seems to be a problem > with the lotus notes browser client. You can use web-based gmane service for posting to the list: http://news.gmane.org/gmane.comp.lib.boost.devel Good luck, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

Boost.Signals and Qt
by Vladimir Prus 23 Sep '05

23 Sep '05

Hi, just came across this blog post: http://scottcollins.net/blog/2005/09/question-for-other-boost-users.html It's from a person affiliated with Trolltech (makers of Qt), and raises a question how Boost.Signals and Qt can be made to better work together. Any user of both Boost and Qt cares to comment? - Volodya

4 8

run_tests.sh portability fix
by Jonathan Wakely 23 Sep '05

23 Sep '05

(sorry for not putting a library name in the subject line, I'm not sure what to put for this) Hi, tools/regression/run_tests.sh uses the "export x=y" syntax, which is not supported by /bin/sh on Solaris9 (and probably other systems.) This means "sh run_tests.sh" or "chmod u+x run_tests.sh; ./run_tests.sh" won't work, you must use /usr/xpg4/bin/sh or another, better, sh. The attached patch fixes the problem, at only a slight readability cost. Is this OK to apply? jon

3 3

Re: [boost] Boost.Signals and Qt
by Martin Bonner 23 Sep '05

23 Sep '05

----Original Message---- From: Simon Buchan [mailto:simon@hand-multimedia.co.nz] Sent: 23 September 2005 09:40 To: boost(a)lists.boost.org Subject: Re: [boost] Boost.Signals and Qt > Vladimir Prus wrote: >> ? Do you mean that the current situation is optimal, and any >> attempts on improving it are just wasting time? >> >> - Volodya >> > Are you serious? You're writing a library! You think someone might use > it with Qt! Yes, dumbass, you SHOULD do that! Take a look at some of > the boost headers (esp. functional, lambda, bind) and THEN bitch > about how hard it is to write a library. > If it hurts your poor fingers (or eyes), put this somewhere useful > (ie. detail namespace): > namespace whatever = ::boost::BOOST_SIGNALS_NAMESPACE; Are *you* serious? Volodya ask if you think the current situation is optimal, and you insult him. I don't see how you post adds to the discussion. -- 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

[serialization docs] Ping?
by David Abrahams 23 Sep '05

23 Sep '05

"Robert Ramey" <ramey(a)rrsd.com> writes: > David Abrahams [mailto:dave@boost-consulting.com] wrote: > > The following message is a courtesy copy of an article > that has been posted to gmane.comp.lib.boost.devel as well. > > > Hi Robert, > > Are you going to reply to > > http://article.gmane.org/gmane.comp.lib.boost.devel/131257 > > ?? > > Thanks, > > I considered your comments and re-wrote the section Archive Concept and it's > checked into RC_1_33_0. It's an improvement, but either you missed or intentionally discarded some of my more important remarks. The most important question was: **** Isn't something in an Archive required to call "serialize?" **** If not, how does an Archive work with Serializable types? > There are two Archive concepts. Given a set of C++ data > structures consisting of Serializable types, a Saving Archive > will create a sequence of bytes. Given a sequence of bytes > created by a Saving Archive, a Loading Archive will reconstitute > the orginal configuration of C++ data structures. Both Archive > concepts are derived from the more basic concept of Archive. This is confusing and self-contradictory. Your text clearly states that there are two Archive concepts and then goes on to describe three Archive concepts: Archive, Saving Archive, and Loading Archive. > Notation > > In the following descriptions, it is assumed that: ^^^^^^^^^^^^^^^^^^^^ Strike this. You are telling the reader what these identifiers mean, not interpreting something about which you need to make some assumption. > • A is an Archive type > • T is an Serializable Type > • ar is an instance of type A. > • x is an instance of type T. > • u is an address. An address is an abstract notion; it doesn't have any value in the type system. You have to say "u is any pointer"... but see below. > Common Type Definitions in all Archives This should be a section for the "Archive" concept. These are not type definitions but valid expressions. > A::is_saving > > An integral constant of type boost::mpl::bool_. I'm sorry to be so blunt, but that's nonsense. A::is_saving is a type, not an integral constant, and boost::mpl::bool_ is a class template, not a type. If you mean to refer to the MPL Integral Constant concept, the correct thing to say would be: A boolean MPL Integral Constant with a link to the documentation for that concept. > Value is boost::mpl::bool_<true> "Value?" This is also nonsense. The ::value member of an MPL Integral Constant is an integral constant, not a type, but boost::mpl::bool_<true> is a type. I normally > if the Archive is a Saving Archive (see below) and > boost::mpl::bool_<false> otherwise. > A::is_loading > > An integral constant of type boost::mpl::bool_. Value is > boost::mpl::bool_<true> if the Archive is a Loading Archive > (see below) and boost::mpl::bool_<false> otherwise. Ditto. > Common Member Functions in all Archives Again, these are not member functions, but valid expressions. Presumably "ar & x" can be implemented by a free function and "ar.template register_type<T>()" invokes a member function template. > ar & x > > Returns a reference to ar. Appends the value of x along with > other information to ar. I think you should swap the two sentences; emphasis should be on effects and only secondarily on return value. But wait. Surely this expression, with the specified semantics, doesn't have to be valid for loading archives? Are you saying that all archives have to be able to save? > ar.template register_type<T>(); You should leave out "template." This is a little tricky, but that expression will never be valid in a context where A is not a dependent type. I realize you do need it when A is a dependent type, but the convention is to use the simpler notation. The author of an archive isn't going to be calling register_type anyway (especially not in a dependent context), so it won't help prevent him from making errors. > ar.register_type(u); > > Append information about class T to the archive. ^--"s" If so then you need to say that u is an expression of type T* > This information is used to construct the correct class when a > derived pointer is loaded. Invocation of this member function is > referred to as "class registration". This is explained in detail > in Special Considerations - Derived Pointers. > ar.library_version() > > Returns an unsigned integer containing the version number of > the serialization library that created the archive. This > number will be incremented each time the library is altered > in such a way that serialization could be altered for some > type. For example, suppose the type used for a count of > collection members is changed. The code that loads > collections might be conditioned on the library version to > make sure that libraries created by previous versions of the > library can still be read. Good! > Saving Archive > > A Saving Archive is a refinement of the Archive Concept. ^--- strike "A." The Saving Archive concept refines Archive. "A saving archive" referes either to a model of Saving Archive or an instance of such a model. > Notation > > In the following descriptions, it is assumed that: > > • ar is an instance of a Saving Archive. > • x is an instance of a Serializable Type. > • u is an address. A pointer again. > • count is an integer that can be converted to std::size_t. ^^^^^^^ no, it's an instance of any type that can be so converted. Your "strong typedef" isn't an integral type. > > Common Member Functions Valid expressions again. > ar << x > > Returns a reference to ar. Appends the value of x along with > other information to ar. Doesn't this have to call serialize(...) somehow? > ar.save_binary(u, count) > > Appends to the archive count bytes found at address. Actually it must be Appends to ar the std::size_t(count) bytes found at address. but doesn't it have to call serialize(...) somehow? > Loading Archive > > Notation > > In the following descriptions, it is assumed that: > > • ar is an instance of a Loading Archive. > • x is an instance of a Serializable Type. > • u, v are pointers to any type. > • count is an integer that can be converted to std::size_t. > > Common Member Functions in all Archives > > ar >> x > > Returns a reference to ar. Sets x with a value retrieved from ^^^^ I would say "to" > the ar. ^^^ strike this. Doesn't this have to call serialize(...) somehow? > ar.load_binary(u, count) > > Retrieves from the archive count bytes and stores them in ^^^^^^^^^^ "ar" > memory starting at address. ^^^^^^^ "u" Doesn't this have to call serialize(...) somehow? > ar.reset_object_address(v, u) > > Communicates to the archive that the object originally at > address u has been moved to address v. > > In order to facilitate loading of objects through a pointer > and to elminate redundant loading of objects, this system > implements object address tracking. Normally this is done > automatically with no action required on the part of the > user. For an implementor of an archive, this whole statement is confusing. Do I need to implement object tracking, or is provided for me somehow by "this system?" Is it done automatically? If so, by whom? I think I know the answers to these questions, but I'm not sure a new reader will. > However, there are cases when an object must be de-serialized to > a temporary location then moved to its final destination. This > is common in loading collections. > > In such cases, reset_object_address should be invoked to > communicate the final address of the last item loaded. This > permits the internal tables to be correctly maintained in > these special cases. > ar.delete_created_pointers() > > Deletes all objects created by the loading of pointers. This > can be used to avoid memory leaks that might otherwise occur if > pointers are being loaded and the archive load encounters an > exception. The following sentence belongs under "Archive Models." > There are archives based on text, binary and XML file formats but > all have the above interface. > Given that all archives present the > same public interface, specifcation of serialization is exactly > the same for all archives. Archive classes have other members not > mentioned here. However they are related to the internal > functioning of the library and are not meant to be called by > users of an archive. Are you telling me, after all this, that there are additional requirements on archives not documented in the section on Archive concepts? I find this rather alarming. Haven't I made it abundantly clear that the concept documentation has to give at least a minimal and complete documentation of what's required of an Archive? > Implementation of new archives is discussed in New Archives - > Implementation. Which then goes on to describe some "input archive" idea that hasn't been defined, etc... <snip> Okay, I don't know what to say at this point. I'm about to give up, because I don't have the time to keep going over this. It sure seems like you want to do this your own way, rather than by following the established practices and norms. If you were just "creative" but still rigorous, it would be one thing, but it doesn't even seem like you're paying close attention to what you yourself are writing. What should I do? > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > > © Copyright Robert Ramey 2002-2004. Distributed under the Boost > Software License, Version 1.0. (See accompanying file > LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) You might want to update the copyright date. -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 17

Boost regression notification (2005-09-22 [RC_1_33_0])
by Douglas Gregor 23 Sep '05

23 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-22T15:34:14Z 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. utility/enable_if Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 127 failures in 9 libraries: concept_check (20) foreach (1) graph (5) random (1) range (3) serialization (70) thread (8) utility/enable_if (16) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 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_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 intel-win32-9_0 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: cw-9_4 test_class_info_load_binary_archive_dll: cw-9_4 intel-win32-8_1 test_class_info_load_text_archive: cw-9_4 test_class_info_load_text_archive_dll: cw-9_4 intel-win32-8_1 test_class_info_load_text_warchive: cw-9_4 test_class_info_load_text_warchive_dll: cw-9_4 intel-win32-8_1 test_class_info_load_xml_archive: cw-9_4 test_class_info_load_xml_archive_dll: cw-9_4 intel-win32-8_1 test_class_info_load_xml_warchive: cw-9_4 test_class_info_load_xml_warchive_dll: cw-9_4 intel-win32-8_1 test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |utility/enable_if| constructors: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dummy_arg_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_templates: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux namespace_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux no_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux partial_specializations: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

3 2

[Boost-bugs] [ boost-Support Requests-1299123 ] Boost.Iostreams and newline translation
by SourceForge.net 23 Sep '05

23 Sep '05

Support Requests item #1299123, was opened at 2005-09-22 15:00 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=1299123&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: jpstanley (jpstanley) Assigned to: Nobody/Anonymous (nobody) Summary: Boost.Iostreams and newline translation Initial Comment: I like the Boost.Iostreams framework in Boost 1.33. But I haven't found a way to make it do exactly what I want. I maintain software that parses files out of disk images instead of the local file system. I'd like to be able to wrap a C++ istream around my raw binary read/seek APIs to make it easier to parse data from disk images and interface with existing code. Boost.Iostreams makes this job a piece of cake--except that I haven't found a way to make the stream act like an ifstream opened in text mode (I'm on Win32, btw). In other words, I'd like to have CR, LF, and CRLF line endings translated into \n when I read the data. There is a newline_filter class provided which does nearly exactly what I want--but it doesn't support seeking. I still need seekg() and tellg() to work. I tried writing my own filter, but I ran into some problems. It seems the Boost stream buffer class is built on the assumption that this will hold: std::streamsize P0 = str.tellg(); str.read(buf, 100); std::streamsize P1 = str.tellg(); assert(P1 - P0 == 100); But with an ifstream opened in text mode, this assertion can fail (P1 - P0 > 100) if two-character CRLF combinations were translated into a one-character newline in the intervening data. Is it possible to implement an input-seekable filter that will let a Boost.Iostream behave this way? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1299123&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 2

Documentation Wizard
by David Abrahams 22 Sep '05

22 Sep '05

Allow me to introduce Rob Stewart in his new role as Boost Documentation Wizard. For some time we've needed a person to establish standards and policy, and to help ensure that Boost library documentation is of the highest quality. Rob has demonstrated both the interest and the aptitude for this job, and the Boost moderators are very pleased that he's accepted our invitation to take it on. He has lots of good ideas, so I'll leave the rest to him. Rob? -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 4

[metamath] Using mpl::numeric_cast
by Cromwell Enage 22 Sep '05

22 Sep '05

Scattered throughout the metamath library are template specializations of numeric metafunction classes like the following: template <> struct times_impl< integral_c_tag , metamath::double_c_tag > { ... } The purpose of mpl::numeric_cast<> (or BOOST_MPL_AUX_NUMERIC_CAST) is to render such specializations unnecessary. I understand that if template instantiation overhead is a problem then the current situation is okay, but if we start implementing more numeric metatypes such as metamath::float_ and/or metamath::long_double_, then the net increase in code size will become an issue. Also included in the last update of my math sublibrary are files from the metamath library that I modified to make use of BOOST_MPL_AUX_NUMERIC_CAST: * In <boost/metamath/double/double.hpp> I modified double_c_tag so that it inherits from boost::mpl::int_<8> (an arbitrary constant higher than zero). * In <boost/metamath/double/integral_to_double.hpp> I added a template specialization of BOOST_MPL_AUX_NUMERIC_CAST that uses integral_to_double<>. * In the other files I deleted the redundant specializations. Let me know what you think. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 6

Re: [boost] [SPAM] Re: [scope_guard] New revision available + naming consideration
by Jason Stewart 22 Sep '05

22 Sep '05

>You're missing the usage of wanting to keep the original undo >behavior, ignore it in some portion of the code, and then >reinstate it later. With the above, it appears that would entail >this sort of usage: > > scope_guard g(my_undo_function); > ... > g = scope_guard(); > ... > g = scope_guard(my_undo_function); > ... > >That introduces a maintenance problem. With the names we're >discussing, you'd write this instead: > > scope_guard g(my_undo_function); > ... > g.dismiss(); // or whatever name is selected > ... > g.protect(); // or whatever name is selected > ... Ok, I can see that. I like the latest suggestion of dismiss/protect. abandon might be another possiblity for dismiss and seems to go with protect. Jason Stewart

1 0

Re: [boost] [Review] xpressive
by Martin Bonner 22 Sep '05

22 Sep '05

----Original Message---- From: Daryle Walker [mailto:darylew@hotmail.com] Sent: 18 September 2005 20:54 To: Boost mailing list Subject: Re: [boost] [Review] xpressive > Making something like: > > std::copy( pieces.begin(), pieces.end(), destination ); > > completely useless isn't unfriendly? > You'll have to use a (mutable) object to store > "pieces.begin()" so you can increment it before the copy ??? Why can't you use: std::copy( ++pieces.begin(), pieces.end(), destination ); -- 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

Re: [boost] BOOST_ASSUME_review_needed?
by brangdon＠cix.compulink.co.uk 22 Sep '05

22 Sep '05

In-Reply-To: <4331E462.8000700(a)dcook.org> darren(a)dcook.org (Darren Cook) wrote (abridged): > But instead of adding BOOST_ASSUME() I'd prefer the use of _assume() in > BOOST_ASSERT be controlled by a define and off by default. It is a > relatively minor optimization so could just be enabled by those who need > the speed and know their code does not do ASSERT(false). If it is controlled by a #define, switching it on would usually affect a large amount of code, with many ASSERTs written by other people. It seems too risky to me. -- Dave Harris, Nottingham, UK.

1 0

[config] win32 identification macros
by Jonathan Turkanis 22 Sep '05

22 Sep '05

Hi, The header <boost/config/select_platform_config.hpp> contains the lines #elif defined(_WIN32) || defined(__WIN32__) || defined(WIN32) // win32: # define BOOST_PLATFORM_CONFIG "boost/config/platform/win32.hpp" Does anyone know why it's necessary to test __WIN32__ and WIN32? A quick test showed that vc6-7.1, cw8-9.4, como 4.3.3, gcc 3.4.2 (minGW), dmc, bcc 5.6.4, and intel 7.1-8.0 all define _WIN32. What's left over? Jonathan

3 6

Re: [boost] BOOST_ASSUME_review_needed?
by brangdon＠cix.compulink.co.uk 22 Sep '05

22 Sep '05

In-Reply-To: <loom.20050921T155516-756(a)post.gmane.org> nesotto(a)cs.aau.dk (Thorsten Ottosen) wrote (abridged): > I don't get it. If you put BOOST_ASSERT( false ) anywhere, then you > effectively say "never exceute this code". Otherwise there is an error > in the assertion itself. Although that's a reasonable point of view, it is not supported by the current documentation, according to which executing BOOST_ASSERT(false) is well-defined and not an error. With some configurations it will invoke boost::assertion_failed(), which will pop up a message box offering to ignore, abort or break into the debugger. As I said in my previous post, I find the current behaviour quite useful. I sometimes use assert as a convenient way of saying, "issue a warning message, but only in debug builds." I actually work with MFC and use their ASSERT macro rather than BOOST_ASSERT. From a selfish point of view I don't care what boost does here because it won't hurt me. My concern is that other people may have used BOOST_ASSERT the same way I use MFC ASSERT. If you're confident no-one has, fine - but I don't see anything in the documentation which says my use is wrong. The documentation does say, "The macro is intended to be used in Boost libraries", which I suppose means we don't need to worry about breaking end-user code. > (The effect of removing an assertion must not be any in a correct > program). Having assert expand to __assume would not be the same as removing it. -- Dave Harris, Nottingham, UK.

7 8

Re: [boost] Errors compiling multi_index hashed.cpp
by Martin Bonner 22 Sep '05

22 Sep '05

----Original Message---- From: David Crayford [mailto:david_crayford@fundi.com.au] Sent: 22 September 2005 15:32 To: boost(a)lists.boost.org Subject: Re: [boost] Errors compiling multi_index hashed.cpp >> 1. Globally search "__IBMCPP__" in the codebase (about 100 >> occurrences) and replace it with, say, BOOST_IBMCPP. >> This task should be simple if you're a Unix man. > > Nitto, I'm an MVS man, but SlickEdit is my friend...although > we do have UNIX systems services running as a task, so I suppose GREP > is the go. > >> 2. Compile your test code with a compiler switch >> defining the macro BOOST_IBMCPP to 600. I think in your case the >> compiler switch is -DBOOST_IBMCPP=600 >> 3. Shake and serve. >> > I'm crossing my fingers. It's define(DBOOST_IBMCPP=600) on MVS. Are you sure about that leading capital D? From a position of TOTAL ignorance of MVS, I would have expected: define(BOOST_IBMCPP=600) If I'm right, I assume this is a copy and paste error - but it might be a copy and paste error that creeps into your test! -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Re: [boost] [scope_guard] New revisionavailable + namingconsideration
by Greer, Joe 22 Sep '05

22 Sep '05

Naming issues are always interesting. You could always use 'attention' when you want the guard to pay attention and 'at_ease' when you want it to remember its commands but not act upon them. 'dismiss' would then mean go have your coffee and be more permanent. joe

1 0

Re: [boost] Errors compiling multi_index hashed.cpp
by David Crayford 22 Sep '05

22 Sep '05

-----boost-bounces@list= s.boost.org wrote: ----- >To: boost(a)lists.boost.org >= ;From: Joaquín Mª López Muñoz >Sent by: boos= t-bounces(a)lists.boost.org >Date: 2005-09-22 07:27PM >Subject: R= e: [boost] Errors compiling multi_index hashed.cpp > >David C= rayford ha escrito: > >> >From: Joaquín Mª López= Muñoz >> >What is the value then of __IBMCPP__ on= your platform? > >> The version is 41060, as des= cribed in the doco snippet >abo defined the BOOST_ASSERT_CONFIG= macro and got the following >error (as expected). >> &= gt;> "Unknown compiler version - ple report the results". &g= t;> I suppos results ;-). Unf UNIX script on an MVS Any &g= t;ideas for a quick fix? > >The compiler version is 6.0, right?= If so, you might want to first >change >the definition of _= _IBMCPP__ to 600, it must lie somewhere inside >your stdlib = >includes (remember to backup first.). If this gets things to compile,>Boost.Config >maintainers should be contacted as for what the b= est method to handle >this is: >a possible approach is to repla= ce __IBMCPP__ for BOOST_IBMCPP >everywhere >in the Bo= ost code base and then define BOOST_IBMCPP in >boost/config/compile= r/vacpp.h so as to handle z/OS deviant case --but >anyway >I'm = sure John Maddock will have better ideas for solving this. > >J= oaquín M López Muñoz >Telefónica, Investigación y Desarroll= o > Thanks Joaquin, actually the z/OS release is 6. I t= ried changing __IBMCPP__ to 600 but it screwed the compile. "'CEE.SCEEH(ALGORITH)'", line 21.6: CCN5859 (S) #e= rror directive: This file to be used only with IBM z/OS C++ V1R2 and lat= er compilers. &n= bsp; = ; &n bsp; = ; &n= bsp; = ; &n bsp; = ; I'm new to this list, how do I contact J= ohn Maddock? BTW, I'm sorry if my mails are mang= led, it seems to be a problem with the lotus notes browser client.

1 0

Re: [boost] Errors compiling multi_index hashed.cpp
by Joaquín Mª López Muñoz 22 Sep '05

22 Sep '05

David Crayford ha escrito: > >From: Joaquín Mª López Muñoz > >What is the value then of __IBMCPP__ on your platform? > The version is 41060, as described in the doco snippet abo defined the BOOST_ASSERT_CONFIG macro and got the following error (as expected). > > "Unknown compiler version - ple report the results". > I suppos results ;-). Unf UNIX script on an MVS Any ideas for a quick fix? The compiler version is 6.0, right? If so, you might want to first change the definition of __IBMCPP__ to 600, it must lie somewhere inside your stdlib includes (remember to backup first.). If this gets things to compile, Boost.Config maintainers should be contacted as for what the best method to handle this is: a possible approach is to replace __IBMCPP__ for BOOST_IBMCPP everywhere in the Boost code base and then define BOOST_IBMCPP in boost/config/compiler/vacpp.h so as to handle z/OS deviant case --but anyway I'm sure John Maddock will have better ideas for solving this. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

BOOST_ASSERT and __assume on MSVC
by Marcin Kalicinski 22 Sep '05

22 Sep '05

Hi All, Have you considered modifying BOOST_ASSERT to use __assume on MSVC? Briefly speaking __assume(expr) is a hint for optimizer that 'expr' evaluates to nonzero. It can help optimize the code. Standalone use of __assume is not recommended because compiler does not check if the assumption is correct, and if it isn't the program is ill formed. But it fits perfectly in ASSERT macro. This way putting many ASSERTs will not only help to verify the code - it will also help the optimizer. Wow! To be sure I did a small test with MSVC: int f(int n) { // __assume(n == 0); if (n == 1) return 1; else return 0; } produces: xor eax, eax cmp DWORD PTR _n$[esp-4], 1 sete al ret 0 with __assume uncommented: xor eax, eax ret 0 And the comparison is gone. Microsoft docs for __assume are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/ht… cheers, Marcin

5 9

Re: [boost] Errors compiling multi_index hashed.cpp
by David Crayford 22 Sep '05

22 Sep '05

-----boost-bounces@= lists.boost.org wrote: ----- >To: boost(a)lists.boost.org >From: Joaquín Mª López Muñoz >Sent by: = boost-bounces(a)lists.boost.org >Date: 2005-09-22 06:00PM >Subjec= t: Re: [boost] Errors compiling multi_index hashed.cpp > > >David Crayford ha escrito: > >> > Hi all, >&= gt; > >> > I've recently downloaded boost to run on an IBM= mainfram z/OS >system >> > (a port of vacpp). I'm tryin= g to compile >multi_index\example\hashed. >> > cpp (wh= ich I called stuff.cpp) >> > and I'm getting the following err= ors. I'm a relative newbie with >C++ >> > so I'm complet= ely bamboozled by the compiler errors. Help with >this >> &g= t; will be greatly appreciated as I am currently in the process of >= > > trying to convince management to switch to C++ from C, and boost >is >> > one of my big hitting selling points. >&= gt; > >> > "'DOC.USER.CPP(STUFF)'", line 47.60: CCN6281 (W= ) "offsetof" >cannot >> > be applied to "struct word_c= ounter_entry". It is not a POD >> > (plain old data) type.<= BR>> >This warning is harmless, check http://tinyurl.com/e44yvfor = info on >how to supress it. > >> I think this problem = is due to a difference in the version number >in the >> _= _IBMCPP__ macro. >> Although the z/OS compiler is ported fro= m VACPP the __IBMCPP__ >macro has a >> different ver= sion number. >> >> >From the z/OS 1.6 programming refe= rence: >> >> __IBMCPP__ C ++ Only. >> >> This macro indicates the version number of the z/OS C++ compiler. >The >> format of the version number that is provided by th= e macro is >integer >> PVRRM, where : P Represents the compi= ler product v 0 for C/370 v 1 >for >> AD/Cycle C/370 and C/C= ++ for MVS/ESA v 2 for OS/390 C/C++ and 4 for >z/OS >> C/C++= v 4 for z/OS C/C++ Release 2 and laterV Represents the >version numb= er >> RR Represents the release number M Represents the modificati= on >numberIn >> z/OS C/C++ Version 1 Release 6, the value of= the macro is 41060. > >I also think your problems must be some= how related to __IBMCPP__. >What is the value then of __I= BMCPP__ on your platform? >boost/config/compiler/vacpp.h triggers= an error if __IBMCPP__ > 600, >so I guess your value's l= ower than that. > >Joaquín M López Muñoz >Telefón= ica, Investigación y Desarrollo > >________ _______________________ 5F_= ______________ >Unsubscribe & other c= hanges: >http://lists.boost.org/mailman/listinfo.cgi/boost The version is 41060, as described in the doco snippet abo= ve. I defined the BOOST_ASSERT_CONFIG macro and got the following error (as expected). "Unknown compiler version - ple= ase run the configure tests and report the results". I suppos= e I had better run the configure tests and report the results ;-). Unf= ortunately I'm not going to have much luck running a UNIX script on an MVS = mainframe... Any ideas for a quick fix?

1 0

Re: [boost] Errors compiling multi_index hashed.cpp
by Joaquín Mª López Muñoz 22 Sep '05

22 Sep '05

David Crayford ha escrito: > > Hi all, > > > > I've recently downloaded boost to run on an IBM mainfram z/OS system > > (a port of vacpp). I'm trying to compile multi_index\example\hashed. > > cpp (which I called stuff.cpp) > > and I'm getting the following errors. I'm a relative newbie with C++ > > so I'm completely bamboozled by the compiler errors. Help with this > > will be greatly appreciated as I am currently in the process of > > trying to convince management to switch to C++ from C, and boost is > > one of my big hitting selling points. > > > > "'DOC.USER.CPP(STUFF)'", line 47.60: CCN6281 (W) "offsetof" cannot > > be applied to "struct word_counter_entry". It is not a POD > > (plain old data) type. This warning is harmless, check http://tinyurl.com/e44yv for info on how to supress it. > I think this problem is due to a difference in the version number in the > __IBMCPP__ macro. > Although the z/OS compiler is ported from VACPP the __IBMCPP__ macro has a > different version number. > > >From the z/OS 1.6 programming reference: > > __IBMCPP__ C ++ Only. > > This macro indicates the version number of the z/OS C++ compiler. The > format of the version number that is provided by the macro is integer > PVRRM, where : P Represents the compiler product v 0 for C/370 v 1 for > AD/Cycle C/370 and C/C++ for MVS/ESA v 2 for OS/390 C/C++ and 4 for z/OS > C/C++ v 4 for z/OS C/C++ Release 2 and laterV Represents the version number > RR Represents the release number M Represents the modification numberIn > z/OS C/C++ Version 1 Release 6, the value of the macro is 41060. I also think your problems must be somehow related to __IBMCPP__. What is the value then of __IBMCPP__ on your platform? boost/config/compiler/vacpp.h triggers an error if __IBMCPP__ > 600, so I guess your value's lower than that. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[any] documentation is not up-to-date
by Alexander Nasonov 22 Sep '05

22 Sep '05

The any_cast documentation ( http://www.boost.org/doc/html/any_cast.html ) doesn't reflect latest changes in any.hpp. Now it's legal to get direct access to any's content using any_cast<ValueType&> syntax. New overload should be added: template<typename T> T any_cast(any & operand); All occurrences of ValueType in the overload template<typename ValueType> ValueType any_cast(const any & operand); should be replaced with T (where T is either ValueType or a reference to ValueType). In section "Returns" replace If passed a value or reference, it returns a copy of the value content if successful. with If passed a value or reference, it returns held value if successful. If T is ValueType, it returns a copy of the held value, otherwise, if T is a (possibly const qualified) reference to ValueType, it returns a reference to the held value. In section "Throws" replace "the overload taking an any value" with "overloads taking an any value" Section "Rationale" should be removed. -- Alexander Nasonov

1 1

Re: [boost] Errors compiling multi_index hashed.cpp
by David Crayford 22 Sep '05

22 Sep '05

> Hi all, > > I've recently downloaded boost to run on an IBM mainfram z/OS system > (a port of vacpp). I'm trying to compile multi_index\example\hashed. > cpp (which I called stuff.cpp) > and I'm getting the following errors. I'm a relative newbie with C++ > so I'm completely bamboozled by the compiler errors. Help with this > will be greatly appreciated as I am currently in the process of > trying to convince management to switch to C++ from C, and boost is > one of my big hitting selling points. > > "/FTS1/tmp/doc/boost/mpl/aux_/integral_wrapper.hpp", line 85.30: > CCN5431 (S) The declarator cannot be qualified with the enclosing > namespace "mpl_". > "'DOC.USER.CPP(STUFF)'", line 47.60: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "'DOC.USER.CPP(STUFF)'", line 47.60: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "'DOC.USER.CPP(STUFF)'", line 47.60: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "'DOC.USER.CPP(STUFF)'", line 51.59: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "'DOC.USER.CPP(STUFF)'", line 51.59: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "'DOC.USER.CPP(STUFF)'", line 51.59: CCN6281 (W) "offsetof" cannot > be applied to "struct word_counter_entry". It is not a POD > (plain old data) type. > "/FTS1/tmp/doc/boost/mpl/aux_/integral_wrapper.hpp", line 85.30: > CCN5431 (S) The declarator cannot be qualified with the enclosing > namespace "mpl_". > "/FTS1/tmp/doc/boost/mpl/has_key.hpp", line 32.20: CCN5408 (S) The > base class "apply<boost::mpl::set0<mpl_::na>, > boost::multi_index::detail::duplicate_tag_mark>" is declared but not > defined. > "/FTS1/tmp/doc/boost/multi_index/detail/no_duplicate_tags.hpp", line > 60.23: CCN5700 (I) The previous message was produced while > processing "struct boost::mpl::has_key<boost::mpl::set0<mpl_::na>, > boost::multi_index::detail::duplicate_tag_mark>". > "/FTS1/tmp/doc/boost/type_traits/is_base_and_derived.hpp", line 200. > 41: CCN5016 (S) The expression must be an integral constant > expression. > "/FTS1/tmp/doc/boost/type_traits/is_base_and_derived.hpp", line 200. > 33: CCN5700 (I) The previous message was produced while > processing "boost::detail::is_base_and_derived_impl<boost:: > multi_index::detail::tag_marker,boost::multi_index::tag<mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na> >::value". > "/FTS1/tmp/doc/boost/type_traits/is_base_and_derived.hpp", line 188. > 8: CCN5700 (I) The previous message was produced while > processing "struct boost::detail::is_base_and_derived_impl<boost:: > multi_index::detail::tag_marker,boost::multi_index::tag<mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na> >". > "/FTS1/tmp/doc/boost/type_traits/is_base_and_derived.hpp", line 209. > 7: CCN6269 (S) The template argument for the non-type template > parameter of type "bool" must be an integral constant expression. > "/FTS1/tmp/doc/boost/multi_index/tag.hpp", line 61.37: CCN5700 (I) > The previous message was produced while processing "struct > boost::is_base_and_derived<boost::multi_index::detail::tag_marker, > boost::multi_index::tag<mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, > mpl_::na,mpl_::na> >". I think this problem is due to a difference in the version number in the __IBMCPP__ macro. Although the z/OS compiler is ported from VACPP the __IBMCPP__ macro has a different version number. >From the z/OS 1.6 programming reference: __IBMCPP__ C ++ Only. This macro indicates the version number of the z/OS C++ compiler. The format of the version number that is provided by the macro is integer PVRRM, where : P Represents the compiler product v 0 for C/370 v 1 for AD/Cycle C/370 and C/C++ for MVS/ESA v 2 for OS/390 C/C++ and 4 for z/OS C/C++ v 4 for z/OS C/C++ Release 2 and laterV Represents the version number RR Represents the release number M Represents the modification numberIn z/OS C/C++ Version 1 Release 6, the value of the macro is 41060. I'm probably the first person to try to use boost on the big iron. The macro __MVS__ is set to 1 if running on z/OS. I'm happy to assist in any way possible in porting boost to z/OS.

1 0

[Review] xpressive review period extended
by Thomas Witt 22 Sep '05

22 Sep '05

Hi, after being declared half-closed (my bad) the review period for Eric Niebler's xpressive library has now been extended until Sunday Sep 25. The original announcement can be found here: http://tinyurl.com/dk2yz Some additional information is in this posting: http://tinyurl.com/dphjc Thomas Review Manager xpressive

1 0

Re: [boost] BOOST_ASSERT and __assume on MSVC
by brangdon＠cix.compulink.co.uk 22 Sep '05

22 Sep '05

In-Reply-To: <dgmfeo$q1v$1(a)sea.gmane.org> kalita(a)poczta.onet.pl (Marcin Kalicinski) wrote (abridged): > I think generally this is a good idea, but it has a small problem. I > would expect that BOOST_ASSUME should turn into __assume when compiled > in "release" mode of MSVC. As of above proposed solution this is not > the case - user additionally needs to define BOOST_DISABLE_ASSERTS to > get __assume. So when NDEBUG is defined and BOOST_DISABLE_ASSERTS is > not (I think this is 99% of cases, because few people actually use > BOOST_DISABLE_ASSERTS), BOOST_ASSUME will expand to BOOST_ASSERT and > the whole thing will be useless. I did not use NDEBUG because BOOST_ASSERT doesn't, and I didn't want to revisit that decision. I imagine the policy is to use fine-grained flags and then add: #ifdef NDEBUG #define BOOST_DISABLE_ASSERTS #endif in a user-editable header somewhere. Arguably there should be a BOOST_DISABLE_ASSUMES, too, but for now I'll use BOOST_DISABLE_ASSERTS. > # define BOOST_ASSUME(e) { BOOST_ASSERT(e); if (e); else __assume(0); } That evaluates e twice, and if e is false it is not clear whether the assert will actually do anything because it could be optimised away. I think: # define BOOST_ASSUME(e) __assume(e) is simpler and better. > There's also a question what should BOOST_ENABLE_ASSERT_HANDLER do with > BOOST_ASSUME? Should it invoke the handler if condition is false? Only if BOOST_DISABLE_ASSERTS is not defined. So the full code would be: #include <boost/config.hpp> #if defined(BOOST_MSVC) && defined(BOOST_DISABLE_ASSERTS) # define BOOST_ASSUME(e) __assume(e) #else # define BOOST_ASSUME(e) BOOST_ASSERT(e) #endif -- Dave Harris, Nottingham, UK.

4 3

Errors compiling multi_index hashed.cpp
by David Crayford 22 Sep '05

22 Sep '05

Hi all, I've recently= downloaded boost to run on an IBM mainfram z/OS system (a port of vacpp). = I'm trying to compile multi_index\example\hashed.cpp (which I called stuf= f.cpp) and I'm getting the following errors. I'm a relative newbie with= C++ so I'm completely bamboozled by the compiler errors. Help with this wi= ll be greatly appreciated as I am currently in the process of trying to con= vince management to switch to C++ from C, and boost is one of my big hittin= g selling points. "/FTS1/tmp/doc/boost/mpl/aux_/integral_wrappe= r.hpp", line 85.30: CCN5431 (S) The declarator cannot be qualified with the= enclosing namespace "mpl_". = ; &n= bsp; ; &n= bsp; = ; &n= bsp; ; &n= bsp; = ; "'DOC.USER.CPP(STUFF)'", line 47.= 60: CCN6281 (W) "offsetof" cannot be applied to "struct word_counter_en= try". It is not a POD (plain old data) type. &= nbsp; &nbs= p; & nbsp; &nbs= p; &= nbsp; &nbs p; &= nbsp; &nbs= p; &= nbsp; "'DOC.USER.CPP(STUFF)'", line= 47.60: CCN6281 (W) "offsetof" cannot be applied to "struct word_counter= _entry". It is not a POD (plain old data) type.&n= bsp; = ; &n bsp; = ; &n= bsp; = ; &n bsp; = ; &n= bsp; "'DOC.USER.CPP(STUFF)'",= line 47.60: CCN6281 (W) "offsetof" cannot be applied to "struct word_cou= nter_entry". It is not a POD (plain old data) typ= e. &= nbsp; &nbs p; &= nbsp; &nbs= p; & nbsp; &nbs= p; &= nbsp; &nbs p; "'DOC.USER.CPP(STUFF= )'", line 51.59: CCN6281 (W) "offsetof" cannot be applied to "struct word= _counter_entry". It is not a POD (plain old dat= a) type. &= nbsp; &nbs p; &= nbsp; &nbs= p; & nbsp; &nbs= p; &= nbsp; &nbs p; "'DOC.USER.CPP= (STUFF)'", line 51.59: CCN6281 (W) "offsetof" cannot be applied to "struct = word_counter_entry". It is not a POD (plain old= data) type. &nb= sp; &nb= sp; = &nb= sp; &nb= sp; "'DOC.USER= .CPP(STUFF)'", line 51.59: CCN6281 (W) "offsetof" cannot be applied to "str= uct word_counter_entry". It is not a POD (plain= old data) type. = ; &n= bsp; ; &n= bsp; = ; &n= bsp; ; &n= bsp; "/FTS1= /tmp/doc/boost/mpl/aux_/integral_wrapper.hpp", line 85.30: CCN5431 (S) = The declarator cannot be qualified with the enclosing namespace "mpl_= ". &= nbsp; &nbs p; &= nbsp; &nbs= p; & nbsp; &nbs= p; &= nbsp; &nbs p; &= nbsp; "/FTS1/tmp/doc/boost/mpl/has_key.hpp", line 32.20: CCN5408 (S) = The base class "apply<boost::mpl::set0<mpl_::na>, &nb= sp; boost::multi_index::detail::duplicate_tag_mark>" is d eclared but not defined. &nb= sp; = &nb sp; = "/FTS1/tmp/doc/boost/multi_index/det ail/no_duplicate_tags.hpp", line 60.23: CCN5700 (I) The previous messag= e was produced while processing "struct boost::mpl::has_key&l t;boost::mpl::set0<mpl_::na>,boost::multi_index::detail::duplicat e_tag_mark>". &= nbsp; "/FTS1/tmp/doc/boost/type_traits/= is_base_and_derived.hpp", line 200.41: CCN5016 (S) The expression mus= t be an integral constant expression. &n= bsp; = ; &n bsp; = ; &n= bsp; = ; &n bsp; = ; &n= bsp; = ; "/FTS1/tmp/doc/boost/type_traits/is_base_and_deri= ved.hpp", line 200.33: CCN5700 (I) The previous message was produced while& nbsp; processing "boost::detail:: is_base_and_derived_impl<boost::multi_index::detail::tag_m ar= ker,boost::multi_index::tag<mpl_::na, &= nbsp; mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na ,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl _::= na,mpl_::na, mpl_::na,mpl_::na,mpl_::na= ,mpl_::na,mpl_::na> >::value". = ; &n= bsp; = ; &n bsp; = ; &n= bsp; "/FTS1/tmp/doc/boost/type_traits/i= s_base_and_derived.hpp", line 188.8: CCN5700 (I) The previous message= was produced while p= rocessing "struct boost::detail::is_base_and_derived_impl<boost: :multi_index::detail::tag_marker,boost::multi_index::tag<mpl_: :n= a, mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mp l_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_ ::na,= mpl_::na, mpl_::na,mpl_::na,mpl_::na,mp= l_::na,mpl_::na> >". &nb= sp; = &nb= sp; &nb= sp; "/FT= S1/tmp/doc/boost/type_traits/is_base_and_derived.hpp", line 209.7: = CCN6269 (S) The template argument for the non-type template parameter= of type "bool" must be an integral constant expression. &= nbsp; &nbs= p; & nbsp; &nbs= p; &= nbsp; "/FTS1/tmp/doc/boost/multi_index/tag.hpp", line 61.37: CCN5700 (I) The p= revious message was produced while processing "struct &nbs p; boost::is_base_and_derived<boost::multi_index::de tail::tag_marker,boost::multi_index::tag<mpl_::na,mpl_::na,mpl = _::na,mpl_::na, mpl_::na,mpl_::na,mpl _::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_: :na,m= pl_::na,mpl_::na,mpl_::na,mpl_::na,mpl_::na, &nb sp; mpl_::na,mpl_::na> >". = ; &n= bsp;

2 2

Boost publicity - article authors?
by Matthew Vogt 21 Sep '05

21 Sep '05

If anyone is interested in writing a brief article publicising boost, the Linux Weekly News (which covers open-source software as much as Linux) would be interested in receiving a submission. If anybody (maybe Björn Karlsson?) has suitable copy ready, the contact details are forwarded below: Matt lwn(a)lwn.net (LWN.net) Sent by: lwn(a)lwn.net 21/09/2005 06:36 AM To: mvogt(a)jupiters.com.au cc: Subject: Re: LWN Development page should cover boost releases Greetings Matt, thanks for the info on Boost. We're always looking for guest authors, if you would be interested in writing up a summary of the Boost project, that would make a good LWN development page lead article. We typically pay around $75 for such articles. We have an author guide here: http://lwn.net/op/AuthorGuide.lwn -Forrest Cook LWN.net - your Linux information source lwn(a)lwn.net -- Matthew Vogt mattvogt(a)warpmail.net -- http://www.fastmail.fm - mmm... Fastmail...

1 0

[wave] build hangs on GNU/Linux/amd64
by Russell Kliese 21 Sep '05

21 Sep '05

I've been trying to build boost on an amd64 machine under Debian Linux but it hangs trying to compile part of the wave library. Is it possible to skip building the wave library as a temporary work around (I am not familiar with jam)? I'm using the deb source package (from 1.33.0) from the unstable Debian distribution: http://packages.debian.org/unstable/source/boost I am building on the stable distribution (i.e. trying to create a back port because of the broken timed mutexes in 1.32). The build gets to: "g++" -c -Wall -ftemplate-depth-255 -D_REENTRANT -g -O0 -fno-inline -pthread -I"bin/boost/libs/wave/build" -I"/home/users/russell/cvs/debPackages/boost/boost_1_33_0" -I "/home/users/russell/cvs/debPackages/boost/boost_1_33_0" -o "bin/boost/libs/wave/build/libboost_wave.a/gcc/debug/threading-multi/instantiate_cpp_literalgrs.o" "/home/users/russell/cvs/debPackages/boost/boost_1_33_0/libs/wave/build/../src/instantiate_cpp_literalgrs.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "bin/boost/libs/wave/build/libboost_wave.a/gcc/debug/threading-multi/instantiate_cpp_literalgrs.o" at which point it hangs (top shows cc1plus using 99.9% CPU). Please let me know if I can supply more info to help debug this problem. Russell Kliese

5 4

[bigint] operator< problem
by Janusz Piwowarski 21 Sep '05

21 Sep '05

Hello I have the problem with boost::bigint (from boost-sandbox). There's minimal example: #include "boost/bigint.hpp" int main (void) { boost::bigint b = 1; while ( b < 1001 ) b *= 10; } Loop never ends; is it known issue? Compiler g++ 3.4.2 (mingw) -- Regards, Janusz

1 0

Re: [boost] Checked Integral Class
by Matt Doyle 21 Sep '05

21 Sep '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Rob Stewart > Sent: Friday, September 16, 2005 2:06 PM > To: boost(a)lists.boost.org > Cc: boost(a)lists.boost.org > Subject: Re: [boost] Checked Integral Class > > > From: "Matt Doyle" <mdoyle(a)a-m-c.com> > > > From: "michael toksvig" <michaeltoksvig(a)yahoo.com> > > > > > add two numbers in the 1-10 range, and you invariably end=20 > > > up with a number=20 > > > > in the 2-20 range > > > > Yep. However, when considering constrained ranges, I find it > > > surprising that the result would be *permitted* to exceed the > > > constraints of the inputs. > > > > IOW, I'd have expect the result to be constrained to be 2-10. > > > Yes, that means that combinations exist that violate that > > > constraint, but at least it wouldn't surprise me. > > > > > YES, that's exactly the point I was trying to make earlier > - you just = > > did a much better job of explaining it :) > > Thanks, if in fact I was addressing your concern. > > > IMO, the constraints and/or policies set forth when the > type was defined = > > must apply for the lifetime of the type. > > To be certain we're talking about the same thing, Michael and I > have been discussing the result of a computation. Built-in types > regularly undergo promotions when participating in such > expressions, so the question is whether something similar should > happen for a checked integral class and what form it should take. > > Michael was positing that the result type should account for the > full range of values possible from the computation. I argued > against that. > > I should also point out that built-in types don't behave that > way; they can overflow silently, but they don't magically gain > range. (The analogy isn't strong, but has some bearing, I > think.) I think we are talking about the same thing but from different angles, consider this simple case; typedef constrained_value<0, 10, policy> MyCV; MyCV a = 6; MyCv b = 8; MyCv c = a + b; // Should fail If the user wants "c" to be able to hold the result of "a + b" he should define a new type that would accommodate it. We are on the same page aren't we? > > -- > > Rob Stewart stewart(a)sig.com > Software Engineer http://www.sig.com > Susquehanna International Group, LLP using std::disclaimer; > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Scanned by Fortigate {X3BTB534}

4 4

[Test] 1.33 compile error for Win9x/ME targets
by Christopher Kohlhoff 21 Sep '05

21 Sep '05

I'm trying to use the Boost Test framework for unit testing in asio but it doesn't work for Win9x/ME targets without a minor fix. The problem is due to boost/test/impl/execution_monitor.ipp only checking for _WIN32_WINNT, when the #define for Win9x/ME is _WIN32_WINDOWS. I had to make the following change to get it to work: @@ -55,7 +55,7 @@ # define BOOST_MS_STRUCTURED_EXCEPTION_HANDLING -# ifndef _WIN32_WINNT +# if !defined(_WIN32_WINNT) && !defined(_WIN32_WINDOWS) # ifdef _WINBASE_ # warning Debugger check disabled. Either define _WIN32_WINNT or include Boost.Test header in front of winbase.h # else I also encountered this as an error, rather than a warning as intended, because #warning is not supported by MSVC. It should probably use #pragma message("...") instead. Cheers, Chris

2 1

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

21 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-21T15:24:10Z 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. utility/enable_if Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 112 failures in 9 libraries: concept_check (20) foreach (1) graph (5) random (1) range (3) serialization (55) thread (8) utility/enable_if (16) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 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_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 intel-win32-9_0 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |utility/enable_if| constructors: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dummy_arg_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_templates: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux namespace_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux no_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux partial_specializations: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

1 0

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

21 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-21T05:00:08Z 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 Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 168 failures in 14 libraries: concept_check (14) filesystem (8) foreach (7) graph (4) math (3) mpl (2) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (41) wave (4) |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 msvc vc-7_1 vc-7_1 |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: 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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc 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| static_mutex_test: msvc |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: cw-9_4 data_member_native: intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 function_native: intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 function_ptr_native: intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 function_ref_native: intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 lvalue_native: intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 member_function_native: intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 template_int_native: intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 template_tpl_native: intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 template_type_native: intel-win32-9_0 intel-win32-9_0 type_emulation: cw-8_3 cw-9_4 cw-9_4 type_native: 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 intel-9.0-linux

1 0

[range] How to extend Boost.Range?
by Eric Niebler 21 Sep '05

21 Sep '05

While investigating test failures with Boost.Foreach, I found this in Boost.Range's documentation for extending the Range library: http://boost.org/libs/range/doc/boost_range.html#minimal_interface This seems to suggest that the only way to extend Boost.Range is for user-defined types to implement a std-container-like interface, with nested iterator and const_iterator types, and begin() and end() member functions. Is this really the intention? I seem to recall some discussion about a more accomodating extensibility mechanism that makes allowances for non-std-container-like user-defined range types. In fact, Boost.Foreach assumes such an interface, with disastrous results. What became of Boost.Range's extensibility mechanism? Is it documented anywhere, and I'm just not seeing it? -- Eric Niebler Boost Consulting www.boost-consulting.com

9 74

[preprocessor][dmc] improved dmc conformance
by Jonathan Turkanis 21 Sep '05

21 Sep '05

Paul, The newest Digital Mars compiler (8.45) appears to pass all the preprocessor tests when the dmc workarounds are removed. (Specifically, I set BOOST_PP_CONFIG_FLAGS() to (0x0000) and removed the 'dmc' directories for good measure; the result is the same if I set BOOST_PP_CONFIG_FLAGS() to BOOST_PP_CONFIG_STRICT()). If you can verify this, you might want to consider removing the workarounds. Since hardly any of Boost compiles on dmc right now (PP being one of the exceptions), there shouldn't be backward compatibility problems. Jonathan

5 9

BOOST_ASSUME review needed?
by Marcin Kalicinski 21 Sep '05

21 Sep '05

Hi All, What is the next step so that we can move forward towards adding BOOST_ASSUME macro to assert.hpp header? There's been a small discussion and so far every participant agreed that it is a nice thing to have. This is a very small addition, just a few lines. Is there a regular review needed? Marcin

4 5

Scons users?
by David Abrahams 21 Sep '05

21 Sep '05

Hi, On the Boost.Build list we were just discussing the fact that some people otherwise inclined towards Boost have chosen Scons over Boost.Build. It would be useful for us to understand some of the reasons why, if some of you wouldn't mind letting us know. No flames, please! -- Dave Abrahams Boost Consulting www.boost-consulting.com

13 21

integer_traits and alpha / gcc bug?
by Stephen Gross 21 Sep '05

21 Sep '05

I ran into a problem including boost/integer_traits.hpp (from boost 1.33.0) on an alpha / tru64 system with gcc 3.3.1. The error produced was: boost/integer_traits.hpp:112:2: #error No WCHAR_MIN and WCHAR_MAX present, please adjust integer_traits<> for your compiler. Looking at the file, I see that integer_traits.hpp considers a number of different platform / compiler possibilities, but that alpha / gcc is not on the list. Has anyone else run into this problem? Anyone have any ideas how integer_traits.hpp should handle this configuration? Thaks in advance, --Steve Stephen Gross Case Western School of Medicine Cleveland, OH "By Grabthar's hammer, by the sons of Worvan, you shall be avenged." - Dr. Lazarus

3 5

[thread][wave] and [1.33.1]
by John Maddock 21 Sep '05

21 Sep '05

I think the regressions for thread and wave libs in the 1.33.1 branch can be removed quite easily if the Jamfiles for these tests stopped using <runtime-link>static. Anyone know if there was/is any rationale for this? The problem is that some platforms either don't have a static-runtime option, or it may be "optional". For example these tests all fail on my Mandriva Linux box because there are no static runtimes supplied. Other Linux versions may supply them, but as can be seen from the regression test results they sometimes cause more trouble that they are worth. BTW, just because the Boost libs are linked statically this does not imply that the runtime must be statically linked (just in case that was causing any confusion). Thanks, John.

5 6

building boost.threads
by Jason Hise 21 Sep '05

21 Sep '05

I need to build the threads library for VC 8.0, and I really don't know where to start. According to the documentation boost.build does not even support this compiler. Can someone explain what steps I would need to take to compile this library, or if it would be easier just send me debug and release builds of the static link lib? Thanks in advance. -Jason

2 2

[Review] [xpressive]
by Fred 20 Sep '05

20 Sep '05

I'd reviewed xpressive sometime last week. Since then, I'd found a place where xpressive might provide a performance improvement over a Spirit grammar that I've been using. I worked for a few days on trying to use xpressive to replace the Spirit grammar. Unfortunately, I ran out of time and wasn't able to finish it. Even so, my experiences might be of interest here. First, I should point out that I really like the library. I ran into a few glitches, but Eric has been able to fix them pretty quickly. It doesn't look as though there are any serious problems with the library. By far the most serious problems that I ran into involved the limitations of the Microsoft VC7.1 compiler. It really doesn't want to see anything harder than a simple static xpressive expression. This is a serious limitation of the library until VC8 comes out for me. Eric says that gcc 3.3+ is a lot better, though I didn't try that. He also says that the VC8 team used an early version of the library for testing, so it might get better at some point. Note that the VC8 beta does at least as well as VC7.1; I can say this with some certainty since my code was pushing VC7.1 pretty close to its limit. I can't really give the performance numbers that I was hoping for since I didn't have time to optimize my xpressive code for anything other than compiling under VC7.1. Once I get to start using the library under a compiler that works better, I'm going to really enjoy playing with xpressive. If nothing else, it seems like a good model to write template meta-programming with. I frequently got intelligible error messages out of it! (Most frequently this involved a Microsoft internal compiler error that pointed to the correct static assert. Though a bit strange, this is actually better than what boost static assert is supposed to do.) Since I now have significantly more experience with the library, I should explicitly reaffirm my support for adding xpressive to boost. -Fred

1 0

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

20 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-20T18:03:42Z 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… 104 failures in 9 libraries: concept_check (19) foreach (1) graph (5) multi_index (1) random (1) range (3) serialization (63) thread (8) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 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_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |multi_index| test_serialization: intel-win32-9_0 |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

1 0

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

20 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-20T05:00:26Z 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 Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 168 failures in 14 libraries: concept_check (14) filesystem (8) foreach (7) graph (4) math (3) mpl (2) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (41) wave (4) |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 msvc vc-7_1 vc-7_1 |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: 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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc 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| static_mutex_test: msvc |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: cw-9_4 data_member_native: intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 function_native: intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 function_ptr_native: intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 function_ref_native: intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 lvalue_native: intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 member_function_native: intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 template_int_native: intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 template_tpl_native: intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 template_type_native: intel-win32-9_0 intel-win32-9_0 type_emulation: cw-8_3 cw-9_4 cw-9_4 type_native: 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 intel-9.0-linux

1 0

call_once on win32
by Anthony Williams 20 Sep '05

20 Sep '05

I just committed a new version to CVS; pretty much the last version I posted with void return, but incorporating John Maddock's changes for generating the name so as to not require std::stringstream, or even strstream. This version is header only, in contrast to the older version (and current versions for other platforms), which required a C++ file. This allows the call_once function to be a template. Note, that windows.h *is not included* --- explicit prototypes are included for the required functions, following the lead of boost/detail/interlocked.hpp (which has been updated to include InterlockedExchange). Despite tendering a version that handles non-void returns, I am not sure how to do it right (destruction order for statics makes it hard), so I have left that out for now. Anthony -- Anthony Williams Software Developer

6 23

[threads] rework notes
by Matt Hurd 20 Sep '05

20 Sep '05

This should probably belong on the wiki, but I can't edit in the wiki (access denied). I've put up a rationale for the thread restructure with basic information as well here http://www.zomojo.com/thread/boost_thread_rework.xhtml Should have some code / structure in place for discussion soon. First thing to agree on is the basic directory structure and header linkage philosophy. Moving house over the next couple of days so contact will be a little sparodic. Note, I'm in Sydney so I work in a different time zone to most. matt matt(a)zomojo.com

11 15

TR1 review manager needed
by John Maddock 20 Sep '05

20 Sep '05

Before I forget (for the 20th time already!), the upcoming review of my TR1 library submission is in need of someone to act as review manager, the review is scheduled to start on September 20th, and details are as follows: Description: ~~~~~~~~ The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. Functionality supported includes: Reference Wrappers Smart Pointers Class template result_of. Function template mem_fn. Function Object Binders. Polymorphic function wrappers. Type Traits. Random Number Generators and Distributions. Tuples. Tuple Interface to std::pair. Fixed Size Array. Hash Function Objects. Regular Expressions. Complex Number Algorithm Overloads. Complex Number Additional Algorithms. Functionality in TR1 but not yet available in this implementation (because they're not in Boost): Mathematical Special Functions. Unordered Associative Set (Hash Table). Unordered Associative Map (Hash Table). C99 C language additions. This library also makes changes to Boost.Config, and adds some new functionality to Boost.Math, reviewers should start with the readme.html in the root directory of the zip file. ~~~~~~~~~~~~~ Available at: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… or at: http://boost-consulting.com/vault/index.php?action=downloadfile&filename=tr… Regards, John.

6 10

[throw_exception] BOOST_NO_EXCEPTIONS and <exception>
by JOAQUIN LOPEZ MU?Z 20 Sep '05

20 Sep '05

boost/throw_exception.hpp includes <exception> when the macro BOOST_NO_EXCEPTIONS is defined. Isn't it likely that an exception-disabled platform won't provide <exception> either? Is there any rationale/compiler survey for this? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[serialization] Doc problems
by David Abrahams 20 Sep '05

20 Sep '05

Hi Robert and Jonathan, In preparing some slides for a course I'm giving, I've been reading through the serialization documentation. Although it's generally well organized and presented, there are a few problems: 1. The menu control doesn't seem to keep the browser's displayed URL in synch with the location being browsed (FireFox on Windows XP). Wasn't that a major coup of Jonathan's menu control? 2. Deserialization of derived classes through base class pointers is an incredibly important subject -- even for many first-time users -- but the instructions for handling it are buried deep in Reference > Serializable Concept > Pointers > Pointers to Objects of Derived Classes (http://www.boost.org/libs/serialization/doc/serialization.html#derivedpoint…) This material _needs_ to be in the tutorial! In fact, the material in the reference section is narrative and tutorial in nature, which seems inappropriate for a reference manual. Maybe you should just move it? 3. In that reference section, '&' is used repeatedly where only '>>' is appropriate. For example: main(){ ... base *b; ar & b; } That can only be confusing. 4. The documentation says that you can write your freestanding serialize() function in namespace boost::serialization, with the strong implication that it will work even on compilers that support ADL. But it won't work unless boost::serialization is an associated namespace of one of the arguments, as demonstrated by the following program: namespace me { class X {}; } namespace boost { namespace serialization { template <class T> int call_serialize(T const& x) { serialize(x); return 0; } void serialize(me::X); }} int y = boost::serialization::call_serialize(me::X()); As far as I can tell, there's no requirement that any of the arguments to serialize have boost::serialization as an associated namespace. 5. Archive Concept Requirements are specified in a completely new, unprecedented way. I can see why you want to write them this way, but the result is that it isn't completely clear which elements of the interface are required and which are optional. For example, there's a colon after the class name. Does the class need to be derived from something? What about the names of function and member template parameters? I know the answer to that one, but a novice might not. What about the default arguments to member functions? Is it okay to write overloads? Also, there's an extra pair of namespace closers in the second archive concept example. 6. In http://www.boost.org/libs/serialization/doc/archive_reference.html#implemen… it says: All input archives should be derived from the following template: template<class Archive> detail::common_iarchive; but that's nowhere to be found in the archive concept requirements. Which is it? Also, that "detail::" is actually nested in the boost::archive namespace, which is not at all clear from the text there. It's not clear to me why archives should live in a namespace other than serialization; if they were in boost::serialization *and* users were required to derive from one of the archive types, that would solve problem 4. -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 56

Re: [boost] Scons users?
by Martin Bonner 20 Sep '05

20 Sep '05

----Original Message---- From: David Abrahams [mailto:dave@boost-consulting.com] Sent: 20 September 2005 12:59 To: boost(a)lists.boost.org Cc: jamboost(a)yahoogroups.com; boost-users(a)lists.boost.org Subject: Re: [boost] Scons users? > Kevin Wheatley <hxpro(a)cinesite.co.uk> writes: > >> David Abrahams wrote: >>> On the Boost.Build list we were just discussing the fact that some >>> people otherwise inclined towards Boost have chosen Scons over >>> Boost.Build. It would be useful for us to understand some of the >>> reasons why, if some of you wouldn't mind letting us know. No >>> flames, please! >> >> not a flame, but some test results (Noel Llopis' Blog) shows a few >> interesting results: >> >> http://tinyurl.com/7fdns (www.gamesfromwithin.com) >> >> These are updated from previously. > > Wow, harsh. The numbers aside, I think his commentary is rather > flame-ish. Well, without the numbers, I agree. But the numbers do rather back him up (except that BoostBuild does seem to be marginally quicker than Scons on three out of four tests, whereas he describes it as "Slower even than Scons!"). Are there any known optimization oportunities in BoostBuild? Are the results an artifact of his test set up? -- 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

[mpl] Updated math sublibrary.
by Cromwell Enage 20 Sep '05

20 Sep '05

A summary of recent changes: * All math-related functionality has been moved to the boost::mpl::math namespace. * exponent<> is now exponential<>. * numeric_caster_rt<> is now runtime_value<>. For those of you who downloaded the previous version yesterday, I've made more changes since then: * monomial<> is now integral_power<>. * A few bugs in the trigonometric functions were fixed. * The euler, exponential, and square_root example programs now showcase Peder Holt's metadouble. Still to come: * Documentation! * natural_logarithm<>, followed by power<>. * An efficient big_integral<> (someday). Cromwell D. Enage ______________________________________________________ Yahoo! for Good Donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/

1 0

Re: [boost] [Review] xpressive
by Eric Niebler 19 Sep '05

19 Sep '05

Daryle Walker wrote: > On 9/15/05 1:10 PM, "Eric Niebler" <eric_at_[hidden]> wrote: > >> In practice, the only reason why you might iterator over > >> all sub-matches is to print them out. Otherwise, the sub-matches are > > accessed > >> randomly, because (for example) the 1st sub-match is a date and the 3rd >> sub-match is an email address, and I'm not interested in the 2nd. See? > > <snip> > > It looks like the current setup is not STL-friendly. Most of the "what" > list is one type of thing, the in-order pieces of the regex parse. The > first item of the list doesn't match that pattern (since it's the whole > parse). I'm guessing that this "old" way wasn't a problem because people > expected 1-based arrays, so the 0-index could be special. That doesn't > work > in a 0-based array culture, like C++ (or C). C++ people would expect the > 0-index element to match the general rule of the list. This mixing of > element types mixes concerns (violating "keep it simple, silly"). A > STL-friendly alternative would to have separate member functions for the > whole-parse and the list-of-parse-pieces, then have a special function > (member or non-member) that generates a regex-culture combined list. > I agree, if we we're only concerned about satisfying people familiar with C++ culture. But we are also trying to satisfy people familiar with regex culture. Every regex package out there I know of that supports back-references begins numbering captures at 1. I don't know why. But I do know that to break with that tradition now would cause massive confusion. Besides, I'm trying to minimize the differences between xpressive's interface and TR1 regex. Is it a wart? OK, I agree. But frankly, I don't feel that this is an ugly enough wart for me to break with established practice. -- Eric Niebler Boost Consulting www.boost-consulting.com

6 8

Re: [boost] BOOST_ASSERT and __assume on MSVC
by brangdon＠cix.compulink.co.uk 19 Sep '05

19 Sep '05

In-Reply-To: <dg7jf6$uf6$1(a)sea.gmane.org> kalita(a)poczta.onet.pl (Marcin Kalicinski) wrote (abridged): > Have you considered modifying BOOST_ASSERT to use __assume on MSVC? It looks to me as though this risks changing the semantics of BOOST_ASSERT in a way which might break existing code. As I read the documentation, currently code like: if (!p) { BOOST_ASSERT( false ); return; } is supported and meaningful. If BOOST_DISABLE_ASSERTS is true, the macro does nothing and the return statement is executed when p is 0. If we change the macro to instead expand to __assume, then the compiler will probably omit both return and the check against zero. The documented behaviour of the code will change. Although I sympathise with the view that a failed assert should be considered undefined behaviour, I personally find the current documented behaviour quite useful. I sometimes use assert as a convenient way of saying, "issue a warning message, but only in debug builds." If we use __assume, we need to clearly distinguish between the old and the new behaviours, at the point of assert. Specifically, I suggest we add a new macro, eg named BOOST_ASSUME(x), which expands to BOOST_ASSERT(x) by default and to __assume(x) when BOOST_DISABLE_ASSERTS is true. This latter case would be documented as causing undefined behaviour if x is false. Programmers can than change their code from BOOST_ASSERT to BOOST_ASSUME at their leisure. If they believe in defensive programming, they may leave some code as BOOST_ASSERT. > Microsoft docs for __assume are here: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng > /htm/msmod_36.asp -- Dave Harris, Nottingham, UK.

4 5

Re: [boost] Beyond the C++ Standard Library: An Introduction to B oost
by Bjorn.Karlsson＠readsoft.com 19 Sep '05

19 Sep '05

Hello Beman, > From: Beman Dawes [mailto:bdawes@acm.org] > > What kind of animal is that on the cover? Some kind of Lemur? Yes, they are lemurs. In case some of you are wondering what lemurs and Boost have in common, I must confess that I have absolutely no idea. My editor, Peter Gordon, came up with the unbelievably far-fetched connection that "Boost is giving a lift to the C++ Standard Library". I think that he, just as you and I did, simply thought that they were just about the cutest things you ever saw. (When deciding which cover picture to go with, I also consulted my six-year-old son, who made it quite clear that the other options were, ahem, less perfect than the one with the lemurs.) > It is about the cutest thing I've seen in a long time. (Don't > tell my office cat I said that.) My lips are sealed. Björn

2 1

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

19 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-19T14:50:08Z 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… 115 failures in 9 libraries: concept_check (20) foreach (1) graph (5) multi_index (1) random (1) range (3) serialization (73) thread (8) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 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_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |multi_index| test_serialization: intel-win32-9_0 |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: gcc-3.2.3-linux test_class_info_load_binary_archive_dll: gcc-3.2.3-linux test_class_info_load_text_archive: gcc-3.2.3-linux test_class_info_load_text_archive_dll: gcc-3.2.3-linux test_class_info_load_text_warchive: gcc-3.2.3-linux test_class_info_load_text_warchive_dll: gcc-3.2.3-linux test_class_info_load_xml_archive: gcc-3.2.3-linux test_class_info_load_xml_archive_dll: gcc-3.2.3-linux test_class_info_load_xml_warchive: gcc-3.2.3-linux test_class_info_load_xml_warchive_dll: gcc-3.2.3-linux test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

1 0

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

19 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-19T05: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 Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 219 failures in 15 libraries: concept_check (14) date_time (5) filesystem (8) foreach (7) graph (4) math (3) mpl (2) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |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 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: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: 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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc 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| static_mutex_test: msvc |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: cw-9_4 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 intel-win32-9_0 function_emulation: cw-9_4 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 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 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 intel-win32-9_0 function_ref_emulation: cw-9_4 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 intel-win32-9_0 lvalue_emulation: cw-9_4 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 intel-win32-9_0 msvc member_function_emulation: cw-9_4 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 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 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 intel-win32-9_0 template_tpl_emulation: cw-9_4 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 intel-win32-9_0 msvc template_type_emulation: cw-9_4 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 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 intel-9.0-linux

1 0

[Review] xpressive
by Thomas Witt 19 Sep '05

19 Sep '05

The review of Eric Niebler's xpressive library begins now and runs through Sunday, September 18. The library is available here: http://www.boost-consulting.com/vault/index.php?directory=Strings%20-% 20Text%20Processing Here is a short introduction that I shamelessly reassembled from the xpressive documentation. xpressive is an advanced, object-oriented regular expression template library for C++. Regular expressions can be written as strings that are parsed at run-time, or as expression templates that are parsed at compile-time. xpressive brings these two approaches seamlessly together and occupies a unique niche in the world of C++ text processing. With xpressive, you can choose to use it much as you would use Boost.Regex, representing regular expressions as strings. Or you can use it as you would use Spirit, writing your regexes as C+ + expressions, enjoying all the benefits of an embedded language dedicated to text manipulation. When writing your review, you may wish to consider the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Please send your reviews either to the Boost list or to me personally. The former is preferred, because it allows the community to consider your review as well. Thanks Thomas Witt Review Manager xpressive Thomas Witt witt(a)acm.org

13 38

GUI
by Benjamin Munson 19 Sep '05

19 Sep '05

Hi. I'm Ben, first time poster, occasional lurker. I've been playing around with ideas for a nice cross platform C++ GUI, something I think is lacking. Is there any interest in this? More importantly, are there any thoughts on how this should best be done, and features that would be needed. My idea was to have a base window class, with child windows derived from that (admitedly my ideas are retardly simple on occasion), and a special toplevel window derived too. The base window class would obviously need a number of virtual functions for mouse/key/painting etc and I'm not sure how much this would affect performance, I expect at most you'd have two or three levels of inheritance working, and maybe a dozen or so virtuals? Because I'd like this to be usable in real-time systems (like games) rather than just event driven ones I thought that a desktop class would work well as a top level control for all the windows. To handle the drawing itself, I thought some kind of canvas object, obviously this would be the most platform specific part, with members for the different drawing operations you might need, lines/rects/blitting etc. I've actually worked up a test version of a lot of this, a win32 version and a glut version. The win32 version obviously uses the win32 api. The glut version uses glut but no acceleration at all, everything is rendered to a bitmap and glBitmap'ed to the screen at the end, so all lines etc use software algorithms. Also, the glut version unfortunately isn't totally portable for font based reasons, I had to use windows fonts since glut doesn't let you use truetype fonts afaik. The test version implements the top level window, a textbox and button class. Another point I'd like advice on is how best to handle the platform specific parts of a library like this. Right now, there are three classes (desktop, canvas and window_top_level) with platform specific parts variables or that need seperate versions of methods. I've just used #defines to configure which platform is used, and for ease of finding things I've grouped the platform specific parts in seperate files (so I have a window_top_level.cpp, window_top_level_glut.cpp and window_top_level_windows.cpp) with the common methods in the named cpp file. I have a feeling this might not be the best way of doing things. And ideas? I think it might be better if each platform has an entire implementation in one file to itself. I'm sorry if this is a bit rambling, it's a bit of a mind dump to be honest. I can stick the demo online if anyone is interested. If you are, let me know. Ben.

6 14

[functional/hash] Reason for failure of hash_float_test on Tru64/CXX
by Markus Schöpflin 19 Sep '05

19 Sep '05

As can be seen at http://tinyurl.com/9lded there is a failure for a very specific test of the hash function on Tru64/cxx65-042. I finally took the time to track this down and it turned out to be due to a bogus return value of std::numeric_limits<long double>::denorm_min(). The good news is that it's fixed in the latest compiler release. But should the failure be marked as expected for older versions of the compiler, or should a workaround be added to the test itself? Any preferences? Markus

2 2

[parameter] efficiency testing
by David Abrahams 19 Sep '05

19 Sep '05

Last week, we were considering using the parameter library in some client software that demands high performance (they are doing massively parallel statistical analysis), so I sat with Matthias Troyer, an expert in high-performance C++, and developed the test that's now checked in at libs/parameter/test/efficiency.cpp. The test was carefully designed to avoid deceptive effects due to dead code elimination, constant propagation, and CPU architecture, and the process of developing it was highly instructive to me personally. We left lots of comments in the code so I'd be able to remember the issuse involved. I recommend reviewing it for anyone interested in how to measure abstraction penalty. One set of results is checked in at libs/parameter/test/timings.txt, and are reproduced below. As you can see, at least on that platform, you don't need to worry about Boost.Parameter slowing your code down; it might even speed your code up! We'd be very interested in seeing results produced with other compilers and/or platforms at the highest optimization levels. ----------------- Test #1 ---------------- Testers: Matthias Troyer, Michael Gauckler, David Abrahams Date: 2005-09-09 Compiler: Cygwin g++-4.0.0 Command lines: g++ -c -o efficiency.o -ftemplate-depth-100 -funroll-loops \ -O3 -finline-functions -Wno-inline -DNDEBUG efficiency.cpp g++ -o efficiency.exe efficiency.o -Wl,--strip-all efficiency && efficiency && efficiency Machine: Dell Inspiron 9300 Intel(R) Pentium(R) M processor 2.00GHz Running on 230 volts AC power Timings: Run #1 results discarded per standard practice Run #2 plain time: 0.75 named parameter time: 0.734 Run #3 plain time: 0.781 named parameter time: 0.766 ----------------------------------------- -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 4

[xpressive] MinGW 3.4.2 ICE
by Cromwell Enage 19 Sep '05

19 Sep '05

Sorry for being last-minute. Attempting to compile samples/main.cpp results in an ICE caused by <boost/xpressive/detail/matchers.hpp>, line 299. I'm guessing MinGW doesn't like the comma used that way? Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 2

[RMI-like-lib] is there any interest in such?
by Slawomir Lisznianski 19 Sep '05

19 Sep '05

I've been thinking of a library that would bring RMI-like capabilities to C++ (RMI stands for Remote Method Invocation). Primary goal, and differentiating feature, of this library is not to rely on IDL-like compiler, hence no cross-language support either -- if you need that, check out CORBA (www.omg.org) or ICE (http://www.zeroc.com) As an example, I'm going to "implement" client and server sides of a trivial calculator using proposed library. Step 1. Define calculator interface ----------------------------------- // // Operations: add, subtract, multiply and divide // struct add { typedef function2<double, double, double> function_type; }; struct subtract { typedef function2<double, double, double> function_type; }; struct multiply { typedef function2<double, double, double> function_type; }; struct divide { typedef function2<double, double, double> function_type; }; // Calculator interface // typedef interface< operation<sum>, operation<subtract>, operation<multiply>, operation<divide> > calculator_i; Step 2. Client invocation ------------------------- // Construct a proxy to the remote calculator // instance. Arguments to the constructor // describe remote object's location (not shown). // proxy<calculator_i> calculator(...); // Call `subtract' on remote object (call // doesn't block). Returned object implements // Asynchronous Completion Token (or Future) // concept. // act<double> res = call<subtract>(calculator, 12, 43); // Retrieve actual result, or get an exception... // double result = res(); Step 3. Server implementation ----------------------------- // Implement actual calculator. // struct calculator_servant { double sum(double a, double b) { return a + b; } ... // other operations here }; // Instantiate calculator servant // calculator_servant servant; // Create a TCP listener. // tcp_listener listener(...) // Create a stub object that acts as an // adapter between transport and a servant. // stub<calculator_i> calculator(listener); // Install operation handlers. // calculator.register_function<add>(bind(&calculator_servant::sum, ref(servant), _1, _2)); ... // register remaining handlers // Start accepting calls. // calculator.activate(); // Block until exiting. // calculator.wait_for_shutdown(); ... -- end of example] I'm fairly satisfied with the client side, but I'm not so enthusiastic about the server side though. For one, it feels less safe. For example, what if a user forgets to register a "handler" for a particular operation? Any way to enforce this at compile time? Typically, say with CORBA, IDL compiler generates operations as pure virtual functions, so at compile time, the user knows what's left out in her servant. On the other side, it's quite powerful too (being able to "bind" functors to operations, that is). Would that be a problem for you or you'd see it as a good feature? Let me know what you think. Cheers, Slawomir Lisznianski

2 4

Re: [boost] [Review] xpressive
by Scott Woods 18 Sep '05

18 Sep '05

* What is your evaluation of the design? Good. It has taken some powerful, established technologies (e.g. regular expressions and parser generators) and delivered a C++ facillity that uses some of the latest C++ techniques. Hosting these technologies within C++ syntax has resulted in some slightly jarring constructs (e.g. prefix "one-or-more", tag assignment) but the set of design decisions made seem very reasonable. There were some corners that got me curious; the following queries are therefore more about curiosity than suggestions for change. 1. What is the benefit of providing the complete match in the first entry of the results? e.g. "what[0]". While this is consistent with a long tradition in RE, after some time with STL it's presence at position zero wasnt as comfortable as I expected. 2. Why the slash syntax in dynamic regex? The resulting requirement for a double is fairly ugly. It may be consistent with something (Perl/ECMA/..?) but on balance is it worth it? 3. Why ">>" and not "," (comma). Did the "set" facillity take priority or does the low precedence of comma just result in a different ugliness (sorry, not really the word I want to use :-). 4. C++ operators and RE operators are not really comfortable bed-fellows. While the operator overloading technique has given something useful and concise was there no flirtation with "key words" (i.e. in the manner of "as_xpr"). "+" could have been "one_or_more( xpr )". Maybe the keyword version is viable as an alternate targeted at beginners? Unjustifiably complex? 5. There didnt appear to be much specific thought given to file processing. Is this another "not yet implemented"? In particular elegant integration with any async I/O facillity arising from sockets and file I/O initiatives. 6. Very interested in the future of "semantic actions". Actions and file processing probably go together? * What is your evaluation of the implementation? Cannot say. Not used. * What is your evaluation of the documentation? Good. I liked the balance of technical terminology combined with some informality. Appeared to be some minor problems such as initially not knowing what "_w" and "_d" meant. Was this my failing or was there a missing definition. Was the later use of "+alpha" and others inconsistent? * What is your evaluation of the potential usefulness of the library? Huge. Some of that answer refers to the usefulness of RE but xpressive is obviously more. There has been some discussion about overlap with regex. It would be nice to clarify that. The uptake of RE within the development community (at least, the one where I live) is almost embarrassingly low. I have seen many circumstances that cried out for the power and rigor of RE that instead got limited, buggy hand-written solutions. The ease-of-use (installation, build and coding) of xpressive might help? * Did you try to use the library? With what compiler? Did you have any problems? No. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in-depth study with a glaring omission; the library was not used. Lack of time, old compiler, employer resistance to boost. * Are you knowledgeable about the problem domain? Yes. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes. Cheers.

8 24

[serialization] portable_binary_archive
by troy d. straszheim 18 Sep '05

18 Sep '05

Hi Robert, boost... I've implemented a portable binary archive, wondering if there is general interest. I've tested (very thoroughly) on our target platforms, which are 32 and 64 bit linux, and osx on a g5, each platform reads and writes archives written by the others, down to the bit. The archive itself is stored little-endian (as the vast majority of my users are on intel hardware) so big-endian platforms are responsible for byteswapping, though this could be configurable. The problem types are (unsigned) long int and long double. For long int, the archive checks to see if it is small enough to fit into 32 bits, if so it stores it in 32 bits, otherwise it throws. For long double, it just throws, as that's 12 bytes on some platforms, 16 on others, no good way to handle this, and the type is seldom used anyhow. Float and double are assumed to be ieee754, and are just handled as blocks of 32 or 64 bytes. So if the write succeeds, the read is guaranteed to. Part of the idea here is that without resorting to widespread use of int32_t and friends, 4-byte-long platforms are always be able to write archives readable on 8-byte-long platforms. On 8-byte-long platforms, you could write archives readable on the smaller machines, but best to choose either int or long long int or a typedef thereof (int32_t or int64_t). The code is at http://svn.resophonic.com/pub/boost, in boost/archive/detail/portable_binary_archive.hpp boost/archive/portable_binary_iarchive.hpp boost/archive/portable_binary_oarchive.hpp libs/serialization/src/portable_binary_iarchive.cpp libs/serialization/src/portable_binary_oarchive.cpp libs/serialization/test/portable_binary_archive.cpp Issues that come to mind: The test isn't boost-test, that'd need rewriting. Haven't tried any of this on microsoft. Maybe there is some preferred way to detect endianness. The decision to go little-endian was relatively arbitrary, maybe the byte-swapping should be configurable. A possibility I considered was to upgrade all 32 bit longs to 64 bit and do the range-check/throw when *reading* (We nixed this idea, preferring to have the error come up sooner rather than later), maybe this should be configurable as well. There's surely platforms out there with other differences that aren't handled, I don't have a good feel for whether they would make the archive useless to a wider audience. The tests require having access to binary archives written on other platforms, haven't yet thought about how to put that together in the boost build/test context. So have a look, let me know if you're interested. Thanks again for a great lib. troy d. straszheim

4 10

boost::spirit inter-grammar rule referencing
by Hugh Hoover 18 Sep '05

18 Sep '05

I have a pair of grammars where one is currently used purely as if it were a single rule in the second grammar. I'm finding that I want to use a second rule in the first grammar for a start rule when invoked from a particular rule in the second grammar. sort of like this: struct grammarA : public grammar<grammarA> { ... struct definition<ScannerT> { ... definition(grammarA const& self) { r_ruleOne = ... r_ruleTwo = ... ... } rule<ScannerT, parser_context<>, parser_tag<ruleOneId> > const & start() const { return r_ruleOne; } }; }; grammarA r_grammarA; struct grammarB : public grammar<grammarB> { struct definition<ScannerT> { ... definition(grammarB const& self) { r_ruleBOne = ( r_grammarA | chseq_p("foo") ); r_ruleBTwo = ( chseq_p("bar") >> ??? r_grammarA.definition.r_ruleTwo ??? ); // obviously bogus - // r_ruleBTwo is currently like the above with just r_grammarA in the second part. ... } ... }; }; Is this possible? grammar_def doesn't appear to apply here - it could work if I wanted to start the WHOLE parse at a different start node, but referenced from another grammar? I can't find any (other) appropriate wordage under "rule" or "grammar" in the spirit docs. is my example understandable? I elided a lot of "boilerplate" to keep it short... I can't separate grammarA::r_ruleTwo from grammarA, it needs other rules in grammarA. I >could< just copy the whole damn grammarA and specify a different start rule, but that just doesn't seem very elegant, no'wuddimean? Hugh Hoover Enumclaw Software

2 1

Checked Integral Class
by Dan McLeran 18 Sep '05

18 Sep '05

I've written a template class to hold a range of valid integral values. My intent was to mimic Ada's ability to define a type like this: type SmallInt is range -10 .. 10; One can then declare objects of this type and any subsequent assignment that violated this range constraint woud throw an exception. I have built a C++ template class that does the same thing: template<typename T, T min, T max> struct CheckedIntegralValue To define a type that can hold the same range as the example above: typedef CheckedIntegralValue<int, -10, 10> SmallIntType; SmallIntType i = -10;//OK SmallIntType i2 = -100;//Will throw an exception at run-time for value out-of-range I won't include the whole thing here, but I can do so if there is enough interest. I have defined most of the operators one needs to use this type just as one would use a 'normal' integer. Would anyone be interested in something like this in the Boost libraries? Regards, Dan McLeran

8 22

condition Win32 based on events
by Roland Schwarz 18 Sep '05

18 Sep '05

While reviewing the current implementation of boost thread in an effort to split the code into platform specific parts for easier maintanace, I looked into the current implementation of condition variables too. Altough I know the past discussions about this topic to some degree, nevertheless I like to drop in another solution for review. The idea is based on the PulseEvent and SetEvent solution of "Strategies for Implementing POSIX Condition Variables on Win32" from Douglas C. Schmidt http://www.cs.wustl.edu/~schmidt/win32-cv-1.html . The most "concise and intuitive" solution there is described as suffering from the so called "lost wakeup bug". Nevertheless I used this as a starting point. To overcome the lost wakeup bug I introduced the concept of a gate, and using stateful (manual reset) events. The gate is closed whenever a broadcast or signal is underway. On entry to wait the gate also has to be passed through, while simultaneously successful entries are recorded. The trick is that the gate can be closed by one thread (the signaling one) and reopened by another (the waiting one). This can be achieved by using a Semaphore instead of a mutex for the gate implementation. Semaphores can be set/reset from different threads. Altough I think I was careful enough, it might well be that I made an mistake. Also since the idea is so simple and it needs so less code for implementation, I am wondering whether someone else came up with this solution. I would be very glad if someone could take a look at the code and show me its pitfalls. For my draft I used VC7.1 on W2K. The code is without error handling yet. The main() implements a small test, simulating a queue that is served by three threads. Code follows: #include <windows.h> #include <boost/thread/thread.hpp> using namespace boost; typedef CRITICAL_SECTION pthread_mutex_t; void pthread_mutex_init(pthread_mutex_t* mutex) { InitializeCriticalSection(mutex); } void pthread_mutex_destroy(pthread_mutex_t* mutex) { DeleteCriticalSection(mutex); } void pthread_mutex_lock(pthread_mutex_t* mutex) { EnterCriticalSection(mutex); } void pthread_mutex_unlock(pthread_mutex_t* mutex) { LeaveCriticalSection(mutex); } // the condition variable implementation starts here // -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- #define SIGNAL 0 #define BROADCAST 1 typedef struct { HANDLE events_[2]; HANDLE gate_; int waiters_; } pthread_cond_t; void pthread_cond_init(pthread_cond_t *cv) { cv->events_[SIGNAL] = CreateEvent(NULL,FALSE,FALSE,NULL); cv->events_[BROADCAST] = CreateEvent(NULL,TRUE,FALSE,NULL); // use a semaphore instead of mutex since // they can be used cross thread cv->gate_ = CreateSemaphore(NULL,1,1,NULL); cv->waiters_ = 0; } void pthread_cond_destroy(pthread_cond_t* cv) { CloseHandle(cv->events_[SIGNAL]); CloseHandle(cv->events_[BROADCAST]); CloseHandle(cv->gate_); } void pthread_cond_wait( pthread_cond_t* cv, pthread_mutex_t* external_mutex) { // we may only enter when no wakeups active // this will prevent the lost wakeup WaitForSingleObject(cv->gate_, INFINITE); ++cv->waiters_; // count waiters passing through ReleaseSemaphore(cv->gate_,1,NULL); LeaveCriticalSection(external_mutex); switch(WaitForMultipleObjects( 2, cv->events_,FALSE,INFINITE)) { // on unblocking of the thread the gate is closed case WAIT_OBJECT_0+SIGNAL: --cv->waiters_; // one is leaving ReleaseSemaphore(cv->gate_,1,NULL);//reopen // no need to reset event, it is automatic break; case WAIT_OBJECT_0+BROADCAST: if (0 == --cv->waiters_) { ResetEvent( cv->events_[BROADCAST]); // last leaving, reopen the gate ReleaseSemaphore(cv->gate_,1,NULL); } break; } EnterCriticalSection(external_mutex); } void pthread_cond_broadcast (pthread_cond_t *cv) { WaitForSingleObject(cv->gate_, INFINITE);//close gate if (cv->waiters_) // if no waiters just reopen gate SetEvent (cv->events_[BROADCAST]); // wake all else ReleaseSemaphore(cv->gate_,1,NULL); } void pthread_cond_signal (pthread_cond_t *cv) { WaitForSingleObject(cv->gate_, INFINITE);//close gate if (cv->waiters_) // if no waiters just reopen gate SetEvent (cv->events_[SIGNAL]); // wake one else ReleaseSemaphore(cv->gate_,1,NULL); } // -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- // the condition variable implementation ends here // a small example for testing follows: // 3 worker threads try to consume input and update output // main thread generates input and then waits until all // input has been processed by checking the output pthread_mutex_t m; pthread_cond_t ci, co; bool run; int input, output, total; int done1, done2, done3; void do_work1() { pthread_mutex_lock(&m); while (run) { while (0 == input && run) pthread_cond_wait(&ci, &m); if (!run) break; --input; ++output; ++done1; pthread_cond_signal(&co); } pthread_mutex_unlock(&m); } void do_work2() { pthread_mutex_lock(&m); while (run) { while (0 == input && run) pthread_cond_wait(&ci, &m); if (!run) break; --input; ++output; ++done2; pthread_cond_signal(&co); } pthread_mutex_unlock(&m); } void do_work3() { pthread_mutex_lock(&m); while (run) { while (0 == input && run) pthread_cond_wait(&ci, &m); if (!run) break; --input; ++output; ++done3; pthread_cond_signal(&co); } pthread_mutex_unlock(&m); } int main(int argc, char* argv) { pthread_mutex_init(&m); pthread_cond_init(&ci); pthread_cond_init(&co); done1 = done2 = done3 = 0; total = input = output = 0; run = true; boost::thread t1(do_work1); boost::thread t2(do_work2); boost::thread t3(do_work3); for (int n = 0; n<1000; ++n) { pthread_mutex_lock(&m); input+=5; total+=5; pthread_cond_broadcast(&ci); pthread_mutex_unlock(&m); } pthread_mutex_lock(&m); while (output < total) pthread_cond_wait(&co, &m); run = false; pthread_cond_broadcast(&ci); pthread_mutex_unlock(&m); t1.join(); t2.join(); t3.join(); pthread_cond_destroy(&co); pthread_cond_destroy(&ci); pthread_mutex_destroy(&m); return 0; } Regards, Roland

4 16

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

18 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-18T14:45:10Z 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… 113 failures in 9 libraries: concept_check (18) foreach (1) graph (5) multi_index (1) random (1) range (3) serialization (73) thread (8) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |multi_index| test_serialization: intel-win32-9_0 |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: gcc-3.2.3-linux test_class_info_load_binary_archive_dll: gcc-3.2.3-linux test_class_info_load_text_archive: gcc-3.2.3-linux test_class_info_load_text_archive_dll: gcc-3.2.3-linux test_class_info_load_text_warchive: gcc-3.2.3-linux test_class_info_load_text_warchive_dll: gcc-3.2.3-linux test_class_info_load_xml_archive: gcc-3.2.3-linux test_class_info_load_xml_archive_dll: gcc-3.2.3-linux test_class_info_load_xml_warchive: gcc-3.2.3-linux test_class_info_load_xml_warchive_dll: gcc-3.2.3-linux test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

1 0

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

18 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-18T05: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. typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 222 failures in 15 libraries: concept_check (14) date_time (5) filesystem (8) foreach (7) graph (4) math (6) mpl (2) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |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 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: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc 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| static_mutex_test: msvc |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: cw-9_4 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 intel-win32-9_0 function_emulation: cw-9_4 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 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 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 intel-win32-9_0 function_ref_emulation: cw-9_4 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 intel-win32-9_0 lvalue_emulation: cw-9_4 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 intel-win32-9_0 msvc member_function_emulation: cw-9_4 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 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 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 intel-win32-9_0 template_tpl_emulation: cw-9_4 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 intel-win32-9_0 msvc template_type_emulation: cw-9_4 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 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 intel-9.0-linux

1 0

[lambda] extension question
by Brock Peabody 18 Sep '05

18 Sep '05

Hi, I'm trying to learn how to make my own lambda compatible function objects and I'm hoping that someone can nudge me in the right direction. My first try is called tuple_element. It takes an index as a template parameter and a tuple as an argument, returning the element at the given index: //should print "x" cout << tuple_element<1>(_1)(tuple<int,std::string>(2, "x")); I've got everything working except for the sig template. tuple_element looks like (mostly copied from lambda source code): template <int Index> struct tuple_element_action {}; template <int Index, typename Arg> inline const lambda_functor< lambda_functor_base< tuple_element_action<Index>, tuple<lambda_functor<Arg> > > > tuple_element(const lambda_functor<Arg>& a) { return lambda_functor_base< tuple_element_action<Index>, tuple<lambda_functor<Arg> > > ( tuple<lambda_functor<Arg> >(a)); } and the action: template<typename Args, int Index> class lambda_functor_base<tuple_element_action<Index>, Args> { public: Args args; template <class T> struct sig : tuples::element<Index,T> {}; explicit lambda_functor_base(const Args& a) : args(a) {} template<class RET, CALL_TEMPLATE_ARGS> RET call(CALL_FORMAL_ARGS) const { return detail::select(get<0>(args), CALL_ACTUAL_ARGS).get<Index>(); } }; When I try to compile my example in VC 7.1 I get an error that seems to indicate that the type being passed to the sig template is boost::tuples::null_type. Everything works if I hardwire it like: template <class T> struct sig { typedef std::string type; }; Any ideas? Thanks, Brock

5 13

[Boost-bugs] [ boost-Bugs-1294420 ] html docs frequently missing key words
by SourceForge.net 18 Sep '05

18 Sep '05

Bugs item #1294420, was opened at 2005-09-18 01:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1294420&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: Ivo Roper (ivolucien) Assigned to: Nobody/Anonymous (nobody) Summary: html docs frequently missing key words Initial Comment: Some (many?) of the html formatted reference docs are missing the name Boost or other key works in their text. Here are some examples: boost_1_33_0/doc/html/threads.html is missing "boost" in several places. Search for "allows C++" or "destructors never" and various others... boost_1_33_0/doc/html/program_options/overview.html is missing other key words or phrases, search for "classes: " and also "describes a number" It's my guess that this is most likely the result of a documentation generator bug or the like and spans all docs that use whatever syntax is used to generate the examples above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1294420&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[range] naming adl functions
by Thorsten Ottosen 18 Sep '05

18 Sep '05

Hi all, Could we agree on a naming scheme/implementation scheme for the customization-points? I prefer range_begin() range_end() range_size() to boost_range_begin() boost_range_end() boost_range_size() and think these identifiers are unique enough, the small amout of global costomization-points taken into consideration. The consequence of this is that other libraries should always call boost::begin() with qualification. This function must always fall back on a function template which implements the default behavior. The consequence for users is that they must - provide hooks in their own namespace wich is then found via ADL. - Users can specialize boost::begin, but not boost::unspecified_namespace::range_begin. - Global functions will not be found. - derived to base-class conversion are not performed before ADL tries to locate a function -Thorsten

3 5

Subobjects placement.
by Adam Badura 18 Sep '05

18 Sep '05

At first english is not my primary language and all my books on C++ are in polish so I have to translate. I'm afraid I'm not using correct words or terms but I will try to be as descripting as possible to be understood. I have a question on placement of subobjects in a class (or struct - what I know of standard this will be the same). In S. Lippman's "Inside the C++ Object Model" I found that standard only guaranties that subobjects are placed in specific sequence (not to get inside details) but there is no guarante that compiler doesn't place some additional objects (for his internal use) at the begining of object in between subobjects or at the end. (I looked also in Stroustrup's "The C++ Programming Language" and "The Design and Evolution of C++" but have found nothing - but I wasn't looking that hard). So, if I have a class: class point2d { public: double x; double y; }; and make an object of it point2d pp = new point2d; than ther is no guaranty that reinterpret_cast<double*>(pp) will give me addres of point2d::x. Normally it no difference but if I want to write a class that for example warps comunication with some hardware than I have to be SURE how data would be allocated in memory becouse it must be correct acording to this hardware specification (if hardware keeps in memory a buffer with a char [for command] and int [for argument]) than I my class members must be so placed in this mamory). Another example is color. If I want to write a class that warps color managemant I want it to be more useable I have to be sure that class class color_argb { public: unsigned char a; unsigned char r; unsigned char g; unsigned char b; }; will use ONLY 4 chars (bytes) and ther will not be any other data placed in memory. If one would be added (for example virtual table pointer) than color_argb could not be used to warp data recevied from and given to many libraries and hardware. I suppose that if I don't use any polimorphism (as virtual functions), inherit only in single line and without virtual base classes and don't use any runtime support that compiler doesn't have any reason to place additional data (but still can use more than 4 bytes to align data for example). But what I know it still MAY do this and relaying on that that it does not have to is dangarous. So how is it? Thanks in advance. Adam Badura

5 4

lock free data structures
by Sashan Govender 17 Sep '05

17 Sep '05

Hi Would there be any interest in a lock free implmentation of common data structures. The goal would be to preserve the integrity of the data in a multi-threaded environment without the use of locks. See http://en.wikipedia.org/wiki/Lock-free_and_wait-free_algorithms for more information. Perhaps a lock-free implementation of the STL might be a good idea?

4 4

Boost regression notification (2005-09-15 [RC_1_33_0])
by Douglas Gregor 17 Sep '05

17 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-15T15:07: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… 594 failures in 12 libraries: concept_check (18) config (1) foreach (1) graph (5) math (3) mpl (1) multi_index (1) random (1) range (3) serialization (549) thread (8) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |config| config_test: mingw-3_4_2 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_serialization: intel-win32-9_0 |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_array_binary_archive: cw-9_5-darwin vc-7_1 test_array_binary_archive_dll: cw-9_5-darwin vc-7_1 test_array_text_archive: cw-9_5-darwin vc-7_1 test_array_text_archive_dll: vc-7_1 test_array_text_warchive: cw-9_5-darwin vc-7_1 test_array_text_warchive_dll: mingw-3_4_2 vc-7_1 test_array_xml_archive: cw-9_5-darwin vc-7_1 test_array_xml_archive_dll: vc-7_1 test_array_xml_warchive: cw-9_5-darwin vc-7_1 test_array_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_binary_binary_archive: vc-7_1 test_binary_binary_archive_dll: vc-7_1 test_binary_text_archive: vc-7_1 test_binary_text_archive_dll: vc-7_1 test_binary_text_warchive: vc-7_1 test_binary_text_warchive_dll: mingw-3_4_2 vc-7_1 test_binary_xml_archive: vc-7_1 test_binary_xml_archive_dll: vc-7_1 test_binary_xml_warchive: vc-7_1 test_binary_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_class_info_load_binary_archive: gcc-3.2.3-linux vc-7_1 test_class_info_load_binary_archive_dll: gcc-3.2.3-linux vc-7_1 test_class_info_load_text_archive: gcc-3.2.3-linux vc-7_1 test_class_info_load_text_archive_dll: gcc-3.2.3-linux vc-7_1 test_class_info_load_text_warchive: gcc-3.2.3-linux vc-7_1 test_class_info_load_text_warchive_dll: gcc-3.2.3-linux mingw-3_4_2 vc-7_1 test_class_info_load_xml_archive: gcc-3.2.3-linux vc-7_1 test_class_info_load_xml_archive_dll: gcc-3.2.3-linux vc-7_1 test_class_info_load_xml_warchive: gcc-3.2.3-linux vc-7_1 test_class_info_load_xml_warchive_dll: gcc-3.2.3-linux mingw-3_4_2 vc-7_1 test_class_info_save_binary_archive: vc-7_1 test_class_info_save_binary_archive_dll: vc-7_1 test_class_info_save_text_archive: vc-7_1 test_class_info_save_text_archive_dll: vc-7_1 test_class_info_save_text_warchive: vc-7_1 test_class_info_save_text_warchive_dll: mingw-3_4_2 vc-7_1 test_class_info_save_xml_archive: vc-7_1 test_class_info_save_xml_archive_dll: vc-7_1 test_class_info_save_xml_warchive: vc-7_1 test_class_info_save_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_contained_class_binary_archive: vc-7_1 test_contained_class_binary_archive_dll: vc-7_1 test_contained_class_text_archive: vc-7_1 test_contained_class_text_archive_dll: vc-7_1 test_contained_class_text_warchive: vc-7_1 test_contained_class_text_warchive_dll: mingw-3_4_2 vc-7_1 test_contained_class_xml_archive: vc-7_1 test_contained_class_xml_archive_dll: vc-7_1 test_contained_class_xml_warchive: vc-7_1 test_contained_class_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_cyclic_ptrs_binary_archive: vc-7_1 test_cyclic_ptrs_binary_archive_dll: vc-7_1 test_cyclic_ptrs_text_archive: vc-7_1 test_cyclic_ptrs_text_archive_dll: vc-7_1 test_cyclic_ptrs_text_warchive: vc-7_1 test_cyclic_ptrs_text_warchive_dll: mingw-3_4_2 vc-7_1 test_cyclic_ptrs_xml_archive: vc-7_1 test_cyclic_ptrs_xml_archive_dll: vc-7_1 test_cyclic_ptrs_xml_warchive: vc-7_1 test_cyclic_ptrs_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_delete_pointer_binary_archive: vc-7_1 test_delete_pointer_binary_archive_dll: vc-7_1 test_delete_pointer_text_archive: vc-7_1 test_delete_pointer_text_archive_dll: vc-7_1 test_delete_pointer_text_warchive: vc-7_1 test_delete_pointer_text_warchive_dll: mingw-3_4_2 vc-7_1 test_delete_pointer_xml_archive: vc-7_1 test_delete_pointer_xml_archive_dll: vc-7_1 test_delete_pointer_xml_warchive: vc-7_1 test_delete_pointer_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_deque_binary_archive: vc-7_1 test_deque_binary_archive_dll: vc-7_1 test_deque_text_archive: vc-7_1 test_deque_text_archive_dll: vc-7_1 test_deque_text_warchive: vc-7_1 test_deque_text_warchive_dll: mingw-3_4_2 vc-7_1 test_deque_xml_archive: vc-7_1 test_deque_xml_archive_dll: vc-7_1 test_deque_xml_warchive: vc-7_1 test_deque_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_binary_archive: vc-7_1 test_derived_binary_archive_dll: vc-7_1 test_derived_class_binary_archive: vc-7_1 test_derived_class_binary_archive_dll: vc-7_1 test_derived_class_ptr_binary_archive: vc-7_1 test_derived_class_ptr_binary_archive_dll: vc-7_1 test_derived_class_ptr_text_archive: vc-7_1 test_derived_class_ptr_text_archive_dll: vc-7_1 test_derived_class_ptr_text_warchive: vc-7_1 test_derived_class_ptr_text_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_class_ptr_xml_archive: vc-7_1 test_derived_class_ptr_xml_archive_dll: vc-7_1 test_derived_class_ptr_xml_warchive: vc-7_1 test_derived_class_ptr_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_class_text_archive: vc-7_1 test_derived_class_text_archive_dll: vc-7_1 test_derived_class_text_warchive: vc-7_1 test_derived_class_text_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_class_xml_archive: vc-7_1 test_derived_class_xml_archive_dll: vc-7_1 test_derived_class_xml_warchive: vc-7_1 test_derived_class_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_text_archive: vc-7_1 test_derived_text_archive_dll: vc-7_1 test_derived_text_warchive: vc-7_1 test_derived_text_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_xml_archive: vc-7_1 test_derived_xml_archive_dll: vc-7_1 test_derived_xml_warchive: vc-7_1 test_derived_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_diamond_binary_archive: vc-7_1 test_diamond_binary_archive_dll: vc-7_1 test_diamond_text_archive: vc-7_1 test_diamond_text_archive_dll: vc-7_1 test_diamond_text_warchive: vc-7_1 test_diamond_text_warchive_dll: mingw-3_4_2 vc-7_1 test_diamond_xml_archive: vc-7_1 test_diamond_xml_archive_dll: vc-7_1 test_diamond_xml_warchive: vc-7_1 test_diamond_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_exported_binary_archive: vc-6_5 vc-7_1 test_exported_binary_archive_dll: vc-6_5 vc-7_1 test_exported_text_archive: vc-6_5 vc-7_1 test_exported_text_archive_dll: vc-6_5 vc-7_1 test_exported_text_warchive: vc-6_5 vc-7_1 test_exported_text_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_exported_xml_archive: vc-6_5 vc-7_1 test_exported_xml_archive_dll: vc-6_5 vc-7_1 test_exported_xml_warchive: vc-6_5 vc-7_1 test_exported_xml_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_list_binary_archive: vc-7_1 test_list_binary_archive_dll: vc-7_1 test_list_ptrs_binary_archive: vc-7_1 test_list_ptrs_binary_archive_dll: vc-7_1 test_list_ptrs_text_archive: vc-7_1 test_list_ptrs_text_archive_dll: vc-7_1 test_list_ptrs_text_warchive: vc-7_1 test_list_ptrs_text_warchive_dll: mingw-3_4_2 vc-7_1 test_list_ptrs_xml_archive: vc-7_1 test_list_ptrs_xml_archive_dll: vc-7_1 test_list_ptrs_xml_warchive: vc-7_1 test_list_ptrs_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_list_text_archive: vc-7_1 test_list_text_archive_dll: vc-7_1 test_list_text_warchive: vc-7_1 test_list_text_warchive_dll: mingw-3_4_2 vc-7_1 test_list_xml_archive: vc-7_1 test_list_xml_archive_dll: vc-7_1 test_list_xml_warchive: vc-7_1 test_list_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_map_binary_archive: vc-7_1 test_map_binary_archive_dll: vc-7_1 test_map_text_archive: vc-7_1 test_map_text_archive_dll: vc-7_1 test_map_text_warchive: vc-7_1 test_map_text_warchive_dll: mingw-3_4_2 vc-7_1 test_map_xml_archive: vc-6_5 vc-7_0 vc-7_1 test_map_xml_archive_dll: vc-6_5 vc-7_0 vc-7_1 test_map_xml_warchive: vc-6_5 vc-7_0 vc-7_1 test_map_xml_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_0 vc-7_1 test_mi_binary_archive: vc-7_1 test_mi_binary_archive_dll: vc-7_1 test_mi_text_archive: vc-7_1 test_mi_text_archive_dll: vc-7_1 test_mi_text_warchive: vc-7_1 test_mi_text_warchive_dll: mingw-3_4_2 vc-7_1 test_mi_xml_archive: vc-7_1 test_mi_xml_archive_dll: vc-7_1 test_mi_xml_warchive: vc-7_1 test_mi_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_multiple_ptrs_binary_archive: vc-7_1 test_multiple_ptrs_binary_archive_dll: vc-7_1 test_multiple_ptrs_text_archive: vc-7_1 test_multiple_ptrs_text_archive_dll: vc-7_1 test_multiple_ptrs_text_warchive: vc-7_1 test_multiple_ptrs_text_warchive_dll: mingw-3_4_2 vc-7_1 test_multiple_ptrs_xml_archive: vc-7_1 test_multiple_ptrs_xml_archive_dll: vc-7_1 test_multiple_ptrs_xml_warchive: vc-7_1 test_multiple_ptrs_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_no_rtti_binary_archive: vc-6_5 vc-7_1 test_no_rtti_binary_archive_dll: vc-6_5 vc-7_1 test_no_rtti_text_archive: vc-6_5 vc-7_1 test_no_rtti_text_archive_dll: vc-6_5 vc-7_1 test_no_rtti_text_warchive: vc-6_5 vc-7_1 test_no_rtti_text_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_no_rtti_xml_archive: vc-6_5 vc-7_1 test_no_rtti_xml_archive_dll: vc-6_5 vc-7_1 test_no_rtti_xml_warchive: vc-6_5 vc-7_1 test_no_rtti_xml_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_non_default_ctor2_binary_archive: vc-7_1 test_non_default_ctor2_binary_archive_dll: vc-7_1 test_non_default_ctor2_text_archive: vc-7_1 test_non_default_ctor2_text_archive_dll: vc-7_1 test_non_default_ctor2_text_warchive: vc-7_1 test_non_default_ctor2_text_warchive_dll: mingw-3_4_2 vc-7_1 test_non_default_ctor2_xml_archive: vc-7_1 test_non_default_ctor2_xml_archive_dll: vc-7_1 test_non_default_ctor2_xml_warchive: vc-7_1 test_non_default_ctor2_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_non_default_ctor_binary_archive: vc-7_1 test_non_default_ctor_binary_archive_dll: vc-7_1 test_non_default_ctor_text_archive: vc-7_1 test_non_default_ctor_text_archive_dll: vc-7_1 test_non_default_ctor_text_warchive: vc-7_1 test_non_default_ctor_text_warchive_dll: mingw-3_4_2 vc-7_1 test_non_default_ctor_xml_archive: vc-7_1 test_non_default_ctor_xml_archive_dll: vc-7_1 test_non_default_ctor_xml_warchive: vc-7_1 test_non_default_ctor_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_non_intrusive_binary_archive: vc-7_1 test_non_intrusive_binary_archive_dll: vc-7_1 test_non_intrusive_text_archive: vc-7_1 test_non_intrusive_text_archive_dll: vc-7_1 test_non_intrusive_text_warchive: vc-7_1 test_non_intrusive_text_warchive_dll: mingw-3_4_2 vc-7_1 test_non_intrusive_xml_archive: vc-7_1 test_non_intrusive_xml_archive_dll: vc-7_1 test_non_intrusive_xml_warchive: vc-7_1 test_non_intrusive_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_null_ptr_binary_archive: vc-7_1 test_null_ptr_binary_archive_dll: vc-7_1 test_null_ptr_text_archive: vc-7_1 test_null_ptr_text_archive_dll: vc-7_1 test_null_ptr_text_warchive: vc-7_1 test_null_ptr_text_warchive_dll: mingw-3_4_2 vc-7_1 test_null_ptr_xml_archive: vc-7_1 test_null_ptr_xml_archive_dll: vc-7_1 test_null_ptr_xml_warchive: vc-7_1 test_null_ptr_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_nvp_binary_archive: vc-7_1 test_nvp_binary_archive_dll: vc-7_1 test_nvp_text_archive: vc-7_1 test_nvp_text_archive_dll: vc-7_1 test_nvp_text_warchive: vc-7_1 test_nvp_text_warchive_dll: mingw-3_4_2 vc-7_1 test_nvp_xml_archive: vc-7_1 test_nvp_xml_archive_dll: vc-7_1 test_nvp_xml_warchive: vc-7_1 test_nvp_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_object_binary_archive: vc-7_1 test_object_binary_archive_dll: vc-7_1 test_object_text_archive: vc-7_1 test_object_text_archive_dll: vc-7_1 test_object_text_warchive: vc-7_1 test_object_text_warchive_dll: mingw-3_4_2 vc-7_1 test_object_xml_archive: vc-7_1 test_object_xml_archive_dll: vc-7_1 test_object_xml_warchive: vc-7_1 test_object_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_optional_binary_archive: vc-7_1 test_optional_binary_archive_dll: vc-7_1 test_optional_text_archive: vc-7_1 test_optional_text_archive_dll: vc-7_1 test_optional_text_warchive: vc-7_1 test_optional_text_warchive_dll: mingw-3_4_2 vc-7_1 test_optional_xml_archive: vc-7_1 test_optional_xml_archive_dll: vc-7_1 test_optional_xml_warchive: vc-7_1 test_optional_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_polymorphic_text_warchive_dll: mingw-3_4_2 test_polymorphic_xml_warchive_dll: mingw-3_4_2 test_primitive_binary_archive: vc-7_1 test_primitive_binary_archive_dll: vc-7_1 test_primitive_text_archive: vc-7_1 test_primitive_text_archive_dll: vc-7_1 test_primitive_text_warchive: vc-7_1 test_primitive_text_warchive_dll: mingw-3_4_2 vc-7_1 test_primitive_xml_archive: vc-7_1 test_primitive_xml_archive_dll: vc-7_1 test_primitive_xml_warchive: vc-7_1 test_primitive_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_recursion_binary_archive: vc-7_1 test_recursion_binary_archive_dll: vc-7_1 test_recursion_text_archive: vc-7_1 test_recursion_text_archive_dll: vc-7_1 test_recursion_text_warchive: vc-7_1 test_recursion_text_warchive_dll: mingw-3_4_2 vc-7_1 test_recursion_xml_archive: vc-7_1 test_recursion_xml_archive_dll: vc-7_1 test_recursion_xml_warchive: vc-7_1 test_recursion_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_registered_binary_archive: vc-7_1 test_registered_binary_archive_dll: vc-7_1 test_registered_text_archive: vc-7_1 test_registered_text_archive_dll: vc-7_1 test_registered_text_warchive: vc-7_1 test_registered_text_warchive_dll: mingw-3_4_2 vc-7_1 test_registered_xml_archive: vc-7_1 test_registered_xml_archive_dll: vc-7_1 test_registered_xml_warchive: vc-7_1 test_registered_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_set_binary_archive: vc-7_1 test_set_binary_archive_dll: vc-7_1 test_set_text_archive: vc-7_1 test_set_text_archive_dll: vc-7_1 test_set_text_warchive: vc-7_1 test_set_text_warchive_dll: mingw-3_4_2 vc-7_1 test_set_xml_archive: vc-7_1 test_set_xml_archive_dll: vc-7_1 test_set_xml_warchive: vc-7_1 test_set_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_binary_archive_dll: vc-6_5 vc-7_1 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_text_archive_dll: vc-6_5 vc-7_1 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_text_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_xml_archive_dll: vc-6_5 vc-7_1 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_xml_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_warchive_dll: borland-5_6_4 mingw-3_4_2 vc-6_5 vc-7_1 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_xml_warchive_dll: borland-5_6_4 mingw-3_4_2 vc-6_5 vc-7_1 test_simple_class_binary_archive: vc-7_1 test_simple_class_binary_archive_dll: vc-7_1 test_simple_class_ptr_binary_archive: vc-7_1 test_simple_class_ptr_binary_archive_dll: vc-7_1 test_simple_class_ptr_text_archive: vc-7_1 test_simple_class_ptr_text_archive_dll: vc-7_1 test_simple_class_ptr_text_warchive: vc-7_1 test_simple_class_ptr_text_warchive_dll: mingw-3_4_2 vc-7_1 test_simple_class_ptr_xml_archive: vc-7_1 test_simple_class_ptr_xml_archive_dll: vc-7_1 test_simple_class_ptr_xml_warchive: vc-7_1 test_simple_class_ptr_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_simple_class_text_archive: vc-7_1 test_simple_class_text_archive_dll: vc-7_1 test_simple_class_text_warchive: vc-7_1 test_simple_class_text_warchive_dll: mingw-3_4_2 vc-7_1 test_simple_class_xml_archive: vc-7_1 test_simple_class_xml_archive_dll: vc-7_1 test_simple_class_xml_warchive: vc-7_1 test_simple_class_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_split_binary_archive: vc-7_1 test_split_binary_archive_dll: vc-7_1 test_split_text_archive: vc-7_1 test_split_text_archive_dll: vc-7_1 test_split_text_warchive: vc-7_1 test_split_text_warchive_dll: mingw-3_4_2 vc-7_1 test_split_xml_archive: vc-7_1 test_split_xml_archive_dll: vc-7_1 test_split_xml_warchive: vc-7_1 test_split_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_tracking_binary_archive: vc-7_1 test_tracking_binary_archive_dll: vc-7_1 test_tracking_text_archive: vc-7_1 test_tracking_text_archive_dll: vc-7_1 test_tracking_text_warchive: vc-7_1 test_tracking_text_warchive_dll: mingw-3_4_2 vc-7_1 test_tracking_xml_archive: vc-7_1 test_tracking_xml_archive_dll: vc-7_1 test_tracking_xml_warchive: vc-7_1 test_tracking_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_unregistered_binary_archive: vc-7_1 test_unregistered_binary_archive_dll: vc-7_1 test_unregistered_text_archive: vc-7_1 test_unregistered_text_archive_dll: vc-7_1 test_unregistered_text_warchive: vc-7_1 test_unregistered_text_warchive_dll: mingw-3_4_2 vc-7_1 test_unregistered_xml_archive: vc-7_1 test_unregistered_xml_archive_dll: vc-7_1 test_unregistered_xml_warchive: vc-7_1 test_unregistered_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_variant_binary_archive: vc-7_1 test_variant_binary_archive_dll: vc-7_1 test_variant_text_archive: vc-7_1 test_variant_text_archive_dll: vc-7_1 test_variant_text_warchive: vc-7_1 test_variant_text_warchive_dll: mingw-3_4_2 vc-7_1 test_variant_xml_archive: vc-7_1 test_variant_xml_archive_dll: vc-7_1 test_variant_xml_warchive: vc-7_1 test_variant_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_vector_binary_archive: vc-7_1 test_vector_binary_archive_dll: vc-7_1 test_vector_text_archive: vc-7_1 test_vector_text_archive_dll: vc-7_1 test_vector_text_warchive: vc-7_1 test_vector_text_warchive_dll: mingw-3_4_2 vc-7_1 test_vector_xml_archive: vc-7_1 test_vector_xml_archive_dll: vc-7_1 test_vector_xml_warchive: vc-7_1 test_vector_xml_warchive_dll: mingw-3_4_2 vc-7_1 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

3 2

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

17 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-17T19:34:08Z 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… 119 failures in 9 libraries: concept_check (18) foreach (1) graph (5) multi_index (1) random (1) range (3) serialization (79) thread (8) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |multi_index| test_serialization: intel-win32-9_0 |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_array_binary_archive: cw-9_5-darwin test_array_binary_archive_dll: cw-9_5-darwin test_array_text_archive: cw-9_5-darwin test_array_text_warchive: cw-9_5-darwin test_array_xml_archive: cw-9_5-darwin test_array_xml_warchive: cw-9_5-darwin test_class_info_load_binary_archive: gcc-3.2.3-linux test_class_info_load_binary_archive_dll: gcc-3.2.3-linux test_class_info_load_text_archive: gcc-3.2.3-linux test_class_info_load_text_archive_dll: gcc-3.2.3-linux test_class_info_load_text_warchive: gcc-3.2.3-linux test_class_info_load_text_warchive_dll: gcc-3.2.3-linux test_class_info_load_xml_archive: gcc-3.2.3-linux test_class_info_load_xml_archive_dll: gcc-3.2.3-linux test_class_info_load_xml_warchive: gcc-3.2.3-linux test_class_info_load_xml_warchive_dll: gcc-3.2.3-linux test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

1 0

[type_traits] [promote] request for fast track review
by alnsn-boost 17 Sep '05

17 Sep '05

I propose to add promote, integral_promotion and floating_point_promotion class templates to type_traits library. You can download it from http://cpp-experiment.sourceforge.net/promote-20050917.tar.gz or browse it online http://cpp-experiment.sourceforge.net/promote-20050917/ I've tried it on different compilers with various success: GNU/Linux (gentoo-hardened): gcc 3.3 and 3.4, Intel 7, 8 and 9 Windows: VC7 free compiler Sparc Solaris: Sun C++ 5.3 and 5.7 See comments at the beginning of promote_enum_test.cpp for what is broken. http://cpp-experiment.sourceforge.net/promote-20050917/libs/type_traits/tes… I used to compile tests on VC6 and I'm pretty sure I can add workarounds if someone is still interested. Actually, it compiled the tests better then VC7. As for Borland 5.5, is_enum is broken and I don't see any reason to support this compiler. -- Alexander

1 0

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

17 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-16T05:00:20Z 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 Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 259 failures in 17 libraries: algorithm/string (1) concept_check (14) date_time (5) filesystem (8) foreach (7) graph (4) iostreams (1) math (6) mpl (2) parameter (17) python (1) regex (36) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |algorithm/string| regex: gcc-3_3-darwin |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 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: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc 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: cw-9_4 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 intel-win32-9_0 function_emulation: cw-9_4 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 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 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 intel-win32-9_0 function_ref_emulation: cw-9_4 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 intel-win32-9_0 lvalue_emulation: cw-9_4 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 intel-win32-9_0 msvc member_function_emulation: cw-9_4 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 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 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 intel-win32-9_0 template_tpl_emulation: cw-9_4 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 intel-win32-9_0 msvc template_type_emulation: cw-9_4 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 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 intel-9.0-linux

1 0

[shmem] New snapshot available in boost vault
by Ion Gaztañaga 17 Sep '05

17 Sep '05

Hi to all, I've just uploaded a new Shmem snapshot to Boost Vault under "Memory" folder. This version includes the following changes: -> Changed some containers' interface according to closed C++ defect reports. -> Optimized node containers so that they store just one allocator instance, which reduces container size and containers constructors performance. -> Added slist container (singly linked list). Changes from SGI implementation: end node is an independent node not embedded and splice_after members take an additional parameter to mimick std::list::splice function. Added support for unequal allocators. -> Added growing capacity to memory management algorithms. This way, Shmem machinery based on memory-mapped files and heap memory can grow when the memory segment has no space for new objects. -> Eliminated basic_raw_xxx classes. basic_named_xxx classes offer the same functionality with just 16 bytes overhead per segment and zero runtime performance. This will help library review. -> Code cleanup and reorganized some files in subdirectories to help maintenance (sorry troubles with broken includes). On-line documentation is as always available here: http://ice.prohosting.com/newfunk/boost/libs/shmem/doc/html/index.html Regards, Ion

1 0

a possible typeof addition
by Arkadiy Vertleyb 17 Sep '05

17 Sep '05

Hi All, Do you think it makes sense to write a utility that, using a syntax like following: template<class T, class U> class foo /*typeof*/ { . . . }; struct bar /*typeof*/ { . . . }; // etc. would generate the typeof registrations? I think it could be quite helpful to those library authors who want to make their libs typeof-enabled, since it would minimise the duplication issue... This utility could be written using Spirit or maybe Python or any other suitable tool. Please let me know. Regards, Arkadiy

4 4

Re: [boost] Constructible numbers? (was: Re: Interest in an arbitrary precision library?)
by Guillaume Melquiond 17 Sep '05

17 Sep '05

Le mercredi 14 septembre 2005 à 02:12 -0400, Daryle Walker a écrit : > On 9/13/05 8:17 AM, "Guillaume Melquiond" wrote: > > [SNIP] > > [1] Rational numbers are constructible. Irrational numbers are > > constructible. Pi, E, and other common mathematical constants are > > constructible. Numbers derived from them are constructible. Omega (the > > halting problem encoding) is not constructible. > > I couldn't find this mathematical definition of "constructible;" is it known > by another term? (The only definition I know of is for those ancient Greek > compass & [unmarked] straight-edge puzzles. But all the associated numbers > for those are a subset of algebraic numbers. By that definition, pi and e > are not constructible, since they're transcendental.) I looked in the > Wikipedia, BTW. But maybe you mistyped; rational and irrational numbers > cover _every_ real number, so you didn't have to specify pi, e, common > constants, or derived values. Sorry, "algebraic" is missing in my sentence; I wanted to express a progression in the complexity of the numbers. As for what I called constructible reals, you can look at the "computable numbers" page in the Wikipedia. I should have checked beforehand that the word I use in French was the one used in English :-) Anyway, my point was: "by definition", computable numbers are the ones a computer can handle in arbitrary precision (emphasis on arbitrary), and they cover a wider range than just rational numbers. Best regards, Guillaume

2 1

Beyond the C++ Standard Library: An Introduction to Boost
by Bjorn.Karlsson＠readsoft.com 17 Sep '05

17 Sep '05

Dear All, A long time ago, I came here--to the Boost developers and Boost users mailing lists--asking for help with reviewing a book about the Boost libraries. Your response was fantastic. Back then, I concluded my email with saying thanks to all Boosters; for the libraries, the ideas, the research, the discussions, and the enthusiasm. Today, when the book is finally shipping, I'd like to extend that thank you to the Boosters who helped make "Beyond the C++ Standard Library" reality. Beman Dawes, Rob Stewart, David Abrahams, Aleksey Gurtovoy, David Brownell, Douglas Gregor, Duane Murphy, Eric Friedman, Eric Niebler, Fernando Cacciola, Frank Griswold, Jaakko Järvi, James Curran, Jeremy Siek, John Maddock, Kevlin Henney, Michiel Salters, Paul Grenyer, Peter Dimov, Phil Boyd, Ronald Garcia, Thorsten Ottosen, Tommy Svensson, and Vladimir Prus; thank you all so much! I sincerely hope that I am giving something back to the amazing Boost community through this book. Best regards, Björn Karlsson

2 1

[thread] condition suffering from lost wakup bug?
by Roland Schwarz 16 Sep '05

16 Sep '05

While reviewing the implementation of the condition variable implementation I came across a case where a "lost wakup" seems to take place. The example is admittedly artificial, but I think still correct code. (I hope someone can proof me wrong.) Could this be an indication that the current implementation is not using Alexander Terekhovs algorithm? If this really is the case we should definitely change our code. On the other side, I constructed the test case, by carefully studying Alexanders algorithm, in order to better understand the design. I did the tests on W2K with Vc7.1. My qeustions: 1) Is this corect code with respect to condition variable semantics (posix thread semantics?) 2) If 1) appplies: Can someone reproduce this on another platform too? Thank you, Roland #include <iostream> #include <boost/thread.hpp> using namespace boost; mutex guard; typedef mutex::scoped_lock lock_type; condition cond; long global_count = 0; long count_for_test = 10000; long global_number_of_threads = 0; long number_of_threads_for_test = 1000; bool global_flag = true; void do_work() { lock_type lock(guard); ++global_number_of_threads; cond.notify_one(); while (global_count < count_for_test) cond.wait(lock); } void do_flag() { lock_type lock(guard); ++global_number_of_threads; cond.notify_one(); while (global_count < count_for_test) { cond.wait(lock); global_flag = false; // Step 3: The following signal occasionally // is beeing lost. See below. cond.notify_one(); } } int main() { thread_group pool; for (long i=0; i < number_of_threads_for_test; ++i) { pool.create_thread( do_work ); } pool.create_thread( do_flag ); { // we wait until all threads are up lock_type lock(guard); while (global_number_of_threads < number_of_threads_for_test+1) cond.wait(lock); } // the loop will run for some time and // then suddenly deadlock for (long j=0; j<count_for_test; ++j) { lock_type lock(guard); ++global_count; // Step 1: We do a heavy notification cond.notify_all(); // Step 2: Then we wait on the same condition. // Since we hold the lock we can be sure // all threads are waiting at this point. // Entering the below wait should // atomically wait and release the lock. // In turn I expect all threads being woken up, // except the main thread since the wait // occures after the notify_all(). // The do_flag thread will signal after // we have entered the below wait. // However the signal occasionally // is beeing lost. Is this kind of a // "lost wakup"? while(global_flag) cond.wait(lock); // deadlocks // When you break in with the debugger // as the deadlock occurs, you can see // that the flag indeed is false, which is a // proof that the signal has been sent. global_flag = true; } pool.join_all(); //result check std::cout << "We should get here without a deadlock\n"; return 0; }

5 21

Re: [boost] Checked Integral Class
by Matt Doyle 16 Sep '05

16 Sep '05

> matt, i don't think your code example disambiguates what rob > and i are > disagreeing on > when you say: > > MyCv c = a + b; // Should fail > > you don't say why you think it should fail. there are (at least) 3 > possibilities: > a) at compile time (because it is an error to try to assign a > 0-20 number to > a 0-10 number) > b) at runtime, during the assignment (because it is an error > to assign a > 0-20 number to a 0-10 number if it is outside the 0-10 range) > c) at runtime, during the addition (because it is an error to > add two 0-10 > numbers if they add up to more than 10) > > i think a) and b) are both useful, and i think rob is advocating c) Your correct, I had thought I understood what Rob is talking about. I think what's causing confusion is that there are really two issues - compile time behavior and runtime behavior. I'm getting the two conditions mixed together because I need both. I need to defend against all three possibilities, I need to catch the programmers mistakes at compile time but I also need to catch the application errors at run time. Scanned by Fortigate {X3BTB534}

1 0

Re: [boost] [filesystem] revised function to determineavailablefile system space
by Greer, Joe 16 Sep '05

16 Sep '05

> In looking at this a bit further, both POSIX and windows distinguish > between > total free space and free space available "to nonprivileged process" > (POSIX) > or "to caller" (Windows). > > To accommodate this, we might have: > > boost::uintmax_t capacity(path const &); > boost::uintmax_t total_free_space(path const &); > boost::uintmax_t available_free_space(path const &); > IMO, total_free_space() and available_free_space() should be tied together so that you can make some relationship between them. If they are implemented as separate calls, then you don't really know what disk activity went on between the first and second calls. I can see a case where the total_free_space might be < than the available_free_space if you called the functions in the wrong order and there was disk activity going on. joe

2 1

Re: [boost] Checked Integral Class
by Matt Doyle 16 Sep '05

16 Sep '05

> From: "michael toksvig" <michaeltoksvig(a)yahoo.com> > > > "Rob Stewart" <stewart(a)sig.com> wrote in message > > > > news:200509161700.j8GH0nHo017101@shannonhoon.balstatdev.susq.com... > > > It's surprising for the result type to have a less restrictive > > > range than the inputs. > > > > add two numbers in the 1-10 range, and you invariably end > up with a number > > in the 2-20 range > > Yep. However, when considering constrained ranges, I find it > surprising that the result would be *permitted* to exceed the > constraints of the inputs. > > IOW, I'd have expect the result to be constrained to be 2-10. > Yes, that means that combinations exist that violate that > constraint, but at least it wouldn't surprise me. > <snip> YES, that's exactly the point I was trying to make earlier - you just did a much better job of explaining it :) IMO, the constraints and/or policies set forth when the type was defined must apply for the lifetime of the type. Matt Scanned by Fortigate {X3BTB534}

2 1

Re: [boost] Checked Integral Class
by Matt Doyle 16 Sep '05

16 Sep '05

> > Maciej Sobczak wrote: > > > > In my opinion both approaches have their uses, just like > std::vector and > > boost::array. > > > > Right. We could support both ways by making the type of range > the value > is checked against configurable. I think of a static_range<> for > compile-time checked values and dynamic_ranges to be setup at runtime. Question though. Which is going to be more useable; having separate methods for static and runtime, or having one that checks the range at compile time and then continues to maintain that original policy for the lifetime of the type? Actually, that might be something that be selectable in the policy class, if it's possible, something like apply_contraints_at [COMPILE_TIME, RUN_TIME, BOTH] Any thoughts? Matt Scanned by Fortigate {X3BTB534}

1 0

Vault: Missing Content? Search?
by Caleb Epstein 16 Sep '05

16 Sep '05

I know content disappaeared from the "Vault" at http://boost-consulting.com/vault/ not long ago, but I thought it had been restored. I am looking for the "factory3.zip "file that used to be there, but I'm unable to find it. In fact most of the directories are currently empty. Also, is there any way to make this interface searchable? While the current neat directory structure is nice, it sure makes it difficult to find an arbitrary file that might be there (e.g. does factory belong in "Containers", "Generic Programming", "Miscellaneous" or someplace else?). A search box would help a lot as the content is expanded over time. -- Caleb Epstein caleb dot epstein at gmail dot com

3 2

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

16 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-16T05:00:20Z 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 Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 259 failures in 17 libraries: algorithm/string (1) concept_check (14) date_time (5) filesystem (8) foreach (7) graph (4) iostreams (1) math (6) mpl (2) parameter (17) python (1) regex (36) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |algorithm/string| regex: gcc-3_3-darwin |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 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: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc 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: cw-9_4 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 intel-win32-9_0 function_emulation: cw-9_4 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 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 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 intel-win32-9_0 function_ref_emulation: cw-9_4 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 intel-win32-9_0 lvalue_emulation: cw-9_4 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 intel-win32-9_0 msvc member_function_emulation: cw-9_4 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 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 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 intel-win32-9_0 template_tpl_emulation: cw-9_4 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 intel-win32-9_0 msvc template_type_emulation: cw-9_4 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 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 intel-9.0-linux

1 0

stl_concept_covering.cpp terminally broken in 1.33.x ?
by John Maddock 16 Sep '05

16 Sep '05

Looking at the regressions for 1.33.1 stl_concept_covering.cpp seems not to compile with any compiler at present. Looking at the source there is one obvious error: out = std::fill_n(out, n, value); But fill_n returns void ! Then there are lots of preprocessor sections along the lines of: #if defined(__GNUC__) typedef less_than_op_first_archetype<> FT; typedef less_than_op_second_archetype<> T; #elif defined(__KCC) // The KAI version of this uses a one-argument less-than function // object. typedef less_than_comparable_archetype<> T; typedef convertible_to_archetype<T> FT; #endif forward_iterator_archetype<FT> fi; T value(dummy_cons); fi = std::lower_bound(fi, fi, value); Which can clearly never compiler on any compiler other than GCC or KCC. However, fixing these issues still doesn't get the code compiling on any platform I have access to. Some of these will be std lib conceptual errors, but *something* should compile this source, otherwise what's the point? Regards, John.

1 0

Fwd: Boost thread library bugs
by Sean Parent 16 Sep '05

16 Sep '05

Begin forwarded message: > From: "Mike Schuster" <schuster(a)adobe.com> > Date: September 15, 2005 6:11:03 PM PDT > To: "Sean Parent" <sparent(a)adobe.com> > Subject: RE: Boost thread library bugs > > > I just downloaded it and took a look. > > Bugs 1) and 2) still exist. > > Bug 3): read_write_mutex had a major rewrite, and looking at the new > code, bug 3) appears to have been discovered and addressed. > However, the > code is quite a bit more complicated (1700 lines versus 1100 lines). I > will do some testing and more investigation in the next few days. > > (By the way, my implementation of a "most useful subset" (in my > opinion) > of read_write_mutex is 100 lines. Boost may have gone overboard > here at > the price of performance.) > > -Mike > > -----Original Message----- > From: Sean Parent [mailto:sparent@adobe.com] > Sent: Thursday, September 15, 2005 3:46 PM > To: Mike Schuster > Subject: Re: Boost thread library bugs > > Have you looked at 1.33.0 yet to see if any of these are fixed? > Sean >

3 2

[regex][1.33.1] Build with MinGW+STLport-5 fails.
by Rene Rivera 16 Sep '05

16 Sep '05

Ran into a problem while verifying building. With the combination of MinGW 3.4.2 - Runtime 3.8 - STLport-5 the *release* variant of Boost.Regex fails to build with this error: In file included from C:/DevRoots/Boost/boost_1_33/boost/regex/v4/regex.hpp:97, from C:/DevRoots/Boost/boost_1_33/boost/regex.hpp:31, from C:\DevRoots\Boost\boost_1_33\libs\regex\build\../src/instances.cpp:30: C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:188: error: duplicate explicit instantiation of `void boost::match_results<BidiIterator, Allocator>::maybe_assign(const boost::match_results<BidiIterator, Allocator>&) [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >]' C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:195: error: duplicate explicit instantiation of `void boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::construct_init(BidiIterator, BidiIterator, boost::match_results<BidiIterator, Allocator>&, const boost::basic_regex<typename traits::char_type, traits>&, boost::regex_constants::match_flag_type) [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >]' C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:196: error: duplicate explicit instantiation of `bool boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::match() [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >]' C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:197: error: duplicate explicit instantiation of `bool boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::find() [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >]' It looks like the code is supposed to be guarded for GCC but it might be conflicting since it's STLport also. Any ideas? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 2

[Boost-bugs] [ boost-Bugs-1292635 ] uBLAS::subslice doesn't work
by SourceForge.net 16 Sep '05

16 Sep '05

Bugs item #1292635, was opened at 2005-09-16 00:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1292635&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: uBLAS::subslice doesn't work Initial Comment: Hello all, I had a problem with compiling a following code for testing subslice() on uBLAS: -- test.cpp #include <boost/numeric/ublas/vector.hpp> #include <boost/numeric/ublas/vector_proxy.hpp> #include <boost/numeric/ublas/io.hpp> int main () { using namespace boost::numeric::ublas; vector<double> v (3); for (int i = 0; i < 3; ++ i) boost::numeric::ublas::subslice (v, 0, 1, 3) (i) = i; std::cout << v << std::endl; } -- end of test.cpp % g++ test.cpp test.cpp: In function `int main()': test.cpp:9: error: no matching function for call to `subslice(boost::numeric::ub las::vector<double, boost::numeric::ublas:: unbounded_array<double, std::allocato r<double> > >&, int, int, int)' I guess this is due to some typos on vector_proxy.hpp. I hope attached patch (from Revision 1.45) helps. Regards, Shun Sakuraba sakuraba {at} cb.k.u-tokyo.ac.jp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1292635&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Fwd: Boost thread library bugs
by Sean Parent 16 Sep '05

16 Sep '05

I don't regularly read the boost mailing list - so please reply directly to me or Mike. Sean Begin forwarded message: > From: "Mike Schuster" <schuster(a)adobe.com> > Date: September 15, 2005 3:42:26 PM PDT > Subject: Boost thread library bugs > > > Here is a summary of several bugs I've discovered over the past few > months in the Boost thread library (version 1_32_0). Sean, please > forward this email to the Boost thread developers. Thanks. > > > > 1) On the PowerPC, the sequence of memory write operations executed > by one processor may be seen by another processor or device in a > different order. This weak write ordering property implies that > when modifying a shared resource, the modifying processor must > execute a sync instruction to make these modifications visible to > all other processors before releasing the lock. I discovered > several situations in the Boost thread library where a sync call is > missing. > > > > call_once: Immediately after the client function returns a lock > variable is set to one. Other processors may see this lock equal to > one before all memory write operations performed by the client > function are completed. A call to __sync() should be made > immediately prior to setting the lock to one. > > > > synchronization class constructors (mutex, read_write_mutex, > condition, etc): Once the class constructor returns, Boost provides > an API where other threads are free to call the synchronization > member functions. However, the memory write operations performed by > the constructor may not have been completed when the member > functions are executed by a different processor. So a call to __sync > () should be made immediately prior to returning from the constructor. > > > > Note that a similar situation occurs between member function calls. > However the MacOS synchronization primitives used by Boost do > perform a sync, so correct operation is guaranteed implicitly as > long the last operation performed by a member function involves an > OS synchronization primitive call. This appears to be the situation > in many places, but there may be places in the Boost library where > this requirement is not met. So someone needs to review all of the > source code for problems of this sort. > > > > 2) On the PowerPC, I have seen situations where call_once deadlocks > in the MPRemoteCall function. I have not been able to diagnose the > problem. Deadlocks occur when call_once is executed by non-main > threads. I believe I have a solution to the problem which uses a > completely different implementation similar to that of the Win32 > version and avoids all calls to MPRemoveCall. Maybe I should submit > this solution to the Boost developers for consideration. > > > > 3) I discovered a deadlock in read_write_mutex. If either of the > alternating scheduling policies are used, the implementation will > deadlock the first reader to arrive when no writers are active. The > deadlock occurs in the function void > read_write_mutex_impl<Mutex>::do_read_lock. If m_state == 0 and > m_num_readers_to_wait == 0 (this holds immediately on > construction), then an arriving reader will hang indefinitely on > m_waiting_readers. There are other related situations where the > BOOST_ASSERT on loop_count fails. > > > > Note I am concerned that such a blatant flaw is present in the > library. This implies that the library has not been very well > tested. This is worrisome especially for a thread library where > threading bugs can be extremely frustrating and hard for uses of > the library to reproduce and diagnose. > > > > -Mike Schuster > > > >

1 0

[ Boost.Timer ] Simple class ...
by rubicant rubicant 15 Sep '05

15 Sep '05

Hey hello people ! I'm new so be nice ;-) I was trying to use boost.timer but it didnt work like i wanted :-) So I made this class wich is very simple and does exactly what one would think it does. // start timer.hpp #include <ctime> class timer { public: timer(); unsigned int elapsed(); // returns elapsed time since ctor or restart() void restart(); // restarts the timer private: unsigned int start_t; }; timer::timer() : start_t(std::time(0)) { } unsigned int timer::elapsed() { return (std::time(0) - start_t); } void timer::restart() { start_t = std::time(0); } // end timer.hpp As you can see its very clean and simple to use enjoy ! ...maybe put it in boost timer ;-D ?

1 0

Re: [boost] Interest in color library.
by Schrom, Brian T 15 Sep '05

15 Sep '05

As was pointed out in the chart thread, the Anti-Grain library (http://www.antigrain.com/index.html) has a lot of features, including classes for a number of different color formats. I'm not sure if they include logical conversions from one space to another. It is a good reference to look at though.

1 0

Re: [boost] Checked Integral Class
by Matt Doyle 15 Sep '05

15 Sep '05

I think I want to disagree with this suggestion. Citing your example a=b should work just fine provided that the value of b will fit within the constraints of a. I think in most situations (but not all) the limits are determined by how the type will ultimately be used and not necessarily on the result of the operation that's taking place. If it doesn't fit, so be it, it's an error. On another note; I liked that earlier suggestion of user definable error handling, I can see where heavy handedness is not always desirable. > also, the type of a binary operator's return value should combine the > intervals of the operands > > e.g. given: > CheckedIntegralValue<int, -10, 100> a; > CheckedIntegralValue<int, -100, 20> b; > > then the type of a+b should be CheckedIntegralValue<int, -110, 120> > > and given: > CheckedIntegralValue<int, -110, 120> sum; > > then sum = a+b, sum = a, and sum = b should all compile just fine > > conversely, a = sum, b = sum, and a = b should not > > this may have been implied, just wanted to make sure > > regards, > > /michael toksvig > <snip> Scanned by Fortigate {X3BTB534}

4 3

[Boost-bugs] [ boost-Support Requests-1292345 ] Linker Problems with VC .NET 2003 / STLPort / Boost
by SourceForge.net 15 Sep '05

15 Sep '05

Support Requests item #1292345, was opened at 2005-09-15 21:07 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=1292345&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: Adrian Grigore (pluggy13) Assigned to: Nobody/Anonymous (nobody) Summary: Linker Problems with VC .NET 2003 / STLPort / Boost Initial Comment: Hi, I have been trying for over 2 days to install Boost in VC .NET 2003 alongside with STLPort , and despite several different settings, I am always getting the same linker errors. First I tried using STLPort 4.6.1 with boost 1.32. Here's a short, but complete description of what I have tried: First I downloaded and unzipped STLPort 4.61. Then I ran the vcvars batch and installed STLPort with nmake clean all -f vc71.mak nmake install -f vc71.mak Then I Installed boost 1.32 with bjam "-sTOOLS=vc-7_1-stlport" "-sSTLPORT_PATH=C:\...\stlport" "-sSTLPORT_VERSIONS=4.6.1" "-sstlport-iostreams=on" install This takes a while to complete, but seems to work fine except for a few errors with the datetime package, which I am not using anyway. I entered the boost / stlport header and lib directories into Visual studio and made sure they are on top of the other include directories. Then I created a dummy project with the following files: stdafx.h: --->>>> #ifdef NDEBUG # undef _STLP_DEBUG #else # define _STLP_DEBUG 1 #endif #define BOOST_LIB_DIAGNOSTIC #include <iostream> #include <tchar.h> <<<--- and the main.cpp: --->>>> #include "stdafx.h" #include <boost/filesystem/convenience.hpp> #include <vector> using namespace _STL; int _tmain(int argc, _TCHAR* argv) { //forcing native mode in boost paths just to make sure that boost::filesystem has to be linked successfully boost::filesystem::path::default_name_check(boost::filesystem::native); vector<int> test; test.push_back(1); vector<int>::iterator Iter=test.begin(); Iter++; int testint=*Iter; // iterator overrun error just to see if the debug mode is working nicely return 0; } <<<--- When I try to compile it, it fails with the following liker errors: --->>>> Compiling... stlport-boost-test.cpp Linking to lib file: libboost_filesystem-vc71-mt-sgdp-1_32.lib Linking... stlport-boost-test.obj : error LNK2019: unresolved external symbol "public: static void __cdecl boost::filesystem::path::default_name_check(bool (__cdecl*)(class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > const &))" (?default_name_check@path@filesystem@boost@@SAXP6A_NABV?$basic_string@DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@@Z@Z) referenced in function _main stlport-boost-test.obj : error LNK2019: unresolved external symbol "bool __cdecl boost::filesystem::native(class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > const &)" (?native@filesystem@boost@@YA_NABV?$basic_string@DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@@Z) referenced in function _main Debug/stlport-boost-test.exe : fatal error LNK1120: 2 unresolved externals Build log was saved at "file://e:\documents and settings\Wunibald Wunderlich\My Documents\Visual Studio Projects\Finity Engine VS 2003\stlport-boost-test\Debug\BuildLog.htm" stlport-boost-test - 3 error(s), 0 warning(s) <<<--- It is obvious from the compiler output that libboost_filesystem-vc71-mt-sgdp-1_32.lib was linked, yet the compiler complains about unresolved symbols. When I comment out the line related to boost::filesystem from tmain(), it works perfectly. But I need boost::filesystem and quite a few other libraries for my real projects, so this is not an option. Also, I have no problem linking to boost when not using stlport, but I'd really like to take advantage of the neat debuging mode built into stlport. Someone from the STLPort forums suggested that I might try the latest CVS versions for boost and STLPort, so I did this yesterday (14th of Sept. 2005). I made sure that what I downloaded from CVS was indeed STLPort 5.0 / Boost 1.33, I recompiled everything and changed the headers path to the new version, but the problem stayed absolutely the same. I am really clueless on how to proceed. I have also tried posting to the boost and stlport forums, but nobody seemed to be able to help. Any help would be immmensely appreciated. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1292345&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[filesystem] revised function to determine available file system space
by Beman Dawes 15 Sep '05

15 Sep '05

I'm planning to add a filesystem function to determine available disk space. Perhaps something like: struct space { boost::uintmax_t available; // bytes available to user boost::uintmax_t total; // total bytes on volume }; space filesystem_space( const path & p ); Comments? How safe is the assumption that uintmax_t is large enough nowadays for any modern compiler on a system supporting large disks. Better suggestions for the names? --Beman PS: this is slightly revised from a post on the users list.

6 11

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

15 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-15T05:00:23Z 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 Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 263 failures in 17 libraries: algorithm/string (1) concept_check (14) date_time (5) filesystem (8) foreach (7) graph (7) iostreams (1) math (6) mpl (2) parameter (18) python (1) regex (36) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |algorithm/string| regex: gcc-3_3-darwin |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 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: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| biconnected_components_test: 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 |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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-4_0-darwin msvc 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: cw-9_4 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 intel-win32-9_0 function_emulation: cw-9_4 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 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 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 intel-win32-9_0 function_ref_emulation: cw-9_4 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 intel-win32-9_0 lvalue_emulation: cw-9_4 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 intel-win32-9_0 msvc member_function_emulation: cw-9_4 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 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 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 intel-win32-9_0 template_tpl_emulation: cw-9_4 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 intel-win32-9_0 msvc template_type_emulation: cw-9_4 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 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 intel-9.0-linux

1 0

[config][1.33.1] MinGW improvements?
by Rene Rivera 15 Sep '05

15 Sep '05

In the past few days I've been trying to get Boost using the upcoming STLport-5 release. In the process I've been checking Boost with the latest MinGW 3.4.2 release. And I found that some things have improved. In particular this change... =================================================================== RCS file: /cvsroot/boost/boost/boost/config/platform/win32.hpp,v retrieving revision 1.17 diff -u -r1.17 win32.hpp --- boost/config/platform/win32.hpp 25 Jul 2004 11:56:27 -0000 1.17 +++ boost/config/platform/win32.hpp 13 Sep 2005 05:54:47 -0000 @@ -24,6 +24,12 @@ # define __STDC_LIMIT_MACROS #endif +#if defined(__MINGW32__) && ((__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ >= 4))) +# define BOOST_HAS_MS_INT64 +# define BOOST_HAS_DIRENT_H +# define BOOST_HAS_UNISTD_H +#endif + // // Win32 will normally be using native Win32 threads, // but there is a pthread library avaliable as an option, =================================================================== I.e. it looks like, after running various tests of libraries that use that functionality, that not only are they present but functioning. OK to commit? ...To the 1.33.1 branch? It also looks like C99 wide char functions are also implemented and working. But I guess not enough for libstdc++ to work, but enough for STLport-5 to work. So with one exception, it should be possible to have MinGW+STLport support all wide char ops. The exceptions are that it doesn't have the non-reentrant wide char functions not in C99; AFAIK. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

4 12

[smart_ptr] Easing the use of smart_ptr in case sorting is required
by Loïc Joly 15 Sep '05

15 Sep '05

Hello everybody, Often , when someone creates a collection of smart_ptr, he wants the collection to be sorted by objects, and not by pointer adresses (this is what is used for instance in ptr_containers). To do that, one can provide his functor to the container/algorithm required, but this is burdensome. I do not think that modifying the current behaviour of smart pointers to make the comparison of smart pointers compare objet would be a good idea (even in cases it is possible to compare by objects, people who do not need this sorting would be impacted by the performances of sorting by objects). However, since this a quite a common thing to do, I wonder wether such a functor could be provided inside the smart_ptr headers, so that people who want to use this option can use it directly. What are your feelings about this idea ? Best regards, -- Loïc

4 4

Re: [boost] Checked Integral Class
by Martin Bonner 15 Sep '05

15 Sep '05

----Original Message---- From: Stephen Gross [mailto:sgross@darwin.epbi.cwru.edu] Sent: 14 September 2005 18:19 To: boost(a)lists.boost.org Subject: Re: [boost] Checked Integral Class >> I've written a template class to hold a range of valid integral >> values. My intent was to mimic Ada's ability to define a type like >> this: >> >> type SmallInt is range -10 .. 10; >> >> One can then declare objects of this type and any subsequent >> assignment that violated this range constraint woud throw an >> exception. >> >> I have built a C++ template class that does the same thing: >> >> template<typename T, T min, T max> >> struct CheckedIntegralValue >> >> To define a type that can hold the same range as the example above: >> >> typedef CheckedIntegralValue<int, -10, 10> SmallIntType; >> >> SmallIntType i = -10;//OK >> SmallIntType i2 = -100;//Will throw an exception at run-time for >> value out-of-range >> >> I won't include the whole thing here, but I can do so if there is >> enough interest. I have defined most of the operators one needs to >> use this type just as one would use a 'normal' integer. >> >> Would anyone be interested in something like this in the Boost >> libraries? > > Since the assignment check is done at runtime (as it has to be), why > make > the range restriction at compile time? Isn't it more useful to have a > class that works more like this: > > === CODE === > CheckedIntegralValue x; > x.setLowerLimit(-5); > x.setUpperLimit(1000); > x = 10; > x = 9000; // Fails at runtime > =========== > > Does this make sense? Because: a) You often have a conceptual type whose limits are known at compile time. Different conceptual types in your program will often have different limits, so you get better typesafety almost for free. b) If you carry the limits in the objects, sizeof(CheckedIntegralValue) >= 3*sizeof(int); if you make them compile time, sizeof(CheckedIntegralValue) >= sizeof(int). Structures which fit in an machine word can more easily be passed in registers. c) By making the limits compile time constants, if you assign an in-range constant the optimizer can eliminate the test entirely. -- 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

Repost (putting together boost::any, mpl::vector, and filter_iterator)
by Stephen Gross 15 Sep '05

15 Sep '05

I've put together a class called 'AnyVector' for doing type-based iteration on a vector. The basic idea is that AnyVector wraps a std::vector<boost::any>. The AnyVector lets you iterate across a subset of the underlying vector by using filter_iterators. The filter iterators, in turn, dereference to the requested type for ease of use. For instance, you can do the following: === CODE === AnyVector<> a; a.push_back(1); a.push_back(std::string("hello")); a.push_back(2); a.push_back(std::string("goodbye")); for(AnyVector<>::Iterator<int> i = a.begin<int>(); i != a.end<int>(); ++i) std::cout << (*i + 5); for(AnyVector<>::Iterator<std::string> i = a.begin<std::string>(); i != a.end<std::string>(); ++i) std::cout << i->length(); ============ Furthermore, you can restrict (at compile-time) which objects are allowed to be inserted into the AnyVector. This is done by listing those types when you create your AnyVector: === CODE ==== AnyVector<int, std::string> a; // Only allows int's and string's a.push_back(3.5); // Fails at compile time - double's not allowed! ============= Would this be a useful addition to boost, or does it already exist somewhere in boost and I just missed it? --Steve Stephen Gross Case Western School of Medicine Cleveland, OH "By Grabthar's hammer, by the sons of Worvan, you shall be avenged." - Dr. Lazarus -- Stephen Gross Case Western School of Medicine Cleveland, OH "By Grabthar's hammer, by the sons of Worvan, you shall be avenged." - Dr. Lazarus

2 2

Interest in an arbitrary precision library?
by Joel Eidsath 15 Sep '05

15 Sep '05

I've used several different arbitrary precision libraries with C++ and I have always been somewhat disappointed. And now I'm finally disappointed enough to start on my own. Here are the attributes that I think a C++ arbitrary precision library needs: 0) As much as possible, the library types should be drop-in replacements for the built-in types. a) This probably means some sort of numeic_limits support. I am unclear on the best implementation of this. b) Any automatic type conversions should behave in an obvious manner. c) Ease of use may take priority over efficiency. 1) The library should be both useful for number theory and a way of improving code robustness by minimizing overflow errors. 2) It should also provide equivalents of the basic C++ math functions. Implementing TR1 functions should be a priority. 3) As well as arbitrary precision, it should provide error range math: 2.00 * 2.00 is not generally the same thing as 2.0 * 2.0 4) It should use fast algorithms for multiplication and division, but instead of trying to compete with other libraries in computation speed (GMP uses hand-coded assembly in places), it should concentrate on code portability and ease of extension. 5) I do not envision any fancy memory management. The "big int" class will probably use a std::vector<int> to store it's implementation data. 6) Providing math functions beyond those already in C++ will not be a priority. a) GCD will be at least one exception to this. 7) It should work well with other Boost libraries where possible. 8) Divide by zero errors for integers should be handled with an exception. 9) Precision for rational numbers may be set as a static member variable or it may not. In the second case, expressions involving rational numbers of different. 10) Drop-in algorithm replacement for various operations might be a nice feature. Comments, suggestions, desired features? Some of the parts of this list are off the top of my head, so feel free to suggest changes. Joel Eidsath

12 58

[metamath] File inclusion and use of static
by Matt Calabrese 15 Sep '05

15 Sep '05

I recently started toying with metamath for use in a current project of mine with some really great results, though I ran into some unintuitive organization in regards to inclusion that should probably be fixed. The main "problem" comes from the fact that double.hpp does not include the arithmetic specializations for double_. The reason why I consider this a problem is that it makes working with generic mathematical metafunctions difficult, as it requires the user of the function to know the inner workings of the metafunction in order to know which associated arithmetic operation files for double to include. For instance: template< typename A, typename B, typename C > struct math_function : ::boost::mpl::plus< ::boost::mpl::times< A, B >, C > { }; Now, this metafunction may be meant to be used with any kind of compile-time values (not just double_). All the file really should be required to include is <boost/mpl/times.hpp> and <boost/mpl/plus.hpp>, or at least declarations of the associated templates. Because of this, with the current layout of metamath, the person using math_function from another file now has the responsibility to include <boost/metamath/double/times.hpp> and <boost/metamath/double/plus.hpp>, otherwise the metafunctions obviously will not work correctly (well, assuming that they are actually instantiated, of course). However, this is not a good solution since it means that the user of math_function must know its implementation details in order to know to include the appropriate metamath double operations. The other alternative would be to include the double operations from the math_function file itself, which also is not a good solution, since it implies that it knows about double, which, considering it is a generic function meant to work with any number of types which comply to the currently unspoken compile-time value abstraction (unspoken for non-integral types, correct me if I'm wrong?), is not feasible. The only truely intuitive, fully functional solution I see is to have double's file include everything it needs to make it conformant to the compile-time value pure abstraction (i.e. all of the proper arithmetic operations). Short of this, there should at least be another file that you can include which includes all of the appropriate operations to make it comply to the proper pure abstraction which programmers would usually include. Also, the files for arithmetic operations currently use ::boost::mpl::apply2, yet never include <boost/mpl/apply.hpp>. Slightly less damaging is that the double_macros file does not include double.hpp, which is more just a little bit annoying, since it requires one to include both files explicitly in order to actually use the macro in any practical situation. Finally, the constants pi, e, etc. are currently defined as being static objects at namespace scope, which, as per Annex D.2 of the C++ standard, is deprecated usage of the static keyword (one should prefer unnamed namespaces instead). "ten" is also left out of these definitions, despite its existance as a typedef in the meta sub-namespace. -- -Matt Calabrese

2 1

[assign] a bug in map_list_of?
by Alexey Bakhvalov 15 Sep '05

15 Sep '05

The following example doesn't compile under VC7.1 and VC8.0b2: [code] #include <boost/assign/list_of.hpp> #include <boost/assert.hpp> #include <map> using namespace std; template<class T> void func1() { } template<class T> void func2() { } void func() { } int _tmain(int argc, _TCHAR* argv[]) { typedef void (*TFunc)(); map<const wchar_t *, TFunc> next = boost::assign::map_list_of<const wchar_t *, TFunc> (L"test1", &func1<char>) (L"test2", &func2<char>) ; } [/code] But if I replace (L"test2", &func2<char>) with (L"test2", &func) or (std::make_pair(L"test2", &func2<char>)) then everything works fine.

2 2

asio file I/O
by Felipe Magno de Almeida 15 Sep '05

15 Sep '05

Hi boosters, I've implemented asynchronous file IO for linux in asio using aio_* functions. I created a class called basic_stream_file (and a typedef called stream_file) with almost the same interface as basic_stream_socket. But with read/write and async_read/async_write functions and an aio_demuxer_service. I writed it for the 0.3.2 version. For now to be able to use this new demuxer, is needed to create a demuxer of type: asio::basic_demuxer<asio::detail::aio_demuxer_service>. The implementation is attached. I didnt had time to test it very much, but it seems to be working okay. There are some problems that are related to aio_* in linux, since it isnt completely implemented in today's kernels and isnt implemented at all in 2.4.* kernels(there are patches however). And the aio_* functions only work really asynchronous for now if used with O_DIRECT and aligned buffers. But at least it could have a single interface for AIO with files in Windows and Linux. I'm planning to write asynchronous file I/O for windows with io completions ports too. IMO it would be interesting to be able to have a single demuxer in windows for file and socket AIO. I'm sending attached a file that uses these classes as an example. It must be linked with -laio and -lpthread and libaio must be installed. (It wasnt in my slackware 10.1, dont know about the default setup of other distributions). Any feedback will be appreciated. Thanks, Felipe. -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."

3 4

[preprocessor] help generating create functions
by Jason Hise 14 Sep '05

14 Sep '05

Background: I am using a few functions which have the following form: void create ( ); template < typename P1 > void create ( P1 p1 ); template < typename P1, typename P2 > void create ( P1 p1, P2 p2 ); [...] I am trying to generate these using the boost preprocessor library, but I am getting an error. This is probably because I do not fully understand how the order of expansion of function-like macros works. The error is: warning C4002: too many actual parameters for macro 'BOOST_PP_IIF_1' My code is as follows: #define BOOST_PP_LOCAL_LIMITS (0, BOOST_SINGLETON_PTR_MAX_CONSTRUCTOR_PARAMS) #define BOOST_PP_LOCAL_MACRO(n) \ BOOST_PP_IF(n, template < BOOST_PP_ENUM_PARAMS(n, typename P) >, \ BOOST_PP_EMPTY()) void create ( BOOST_PP_ENUM_BINARY_PARAMS(n, \ typename ::boost::call_traits < P, >::param_type p ) ) \ { \ policy_ptr->get_creator ( )->create \ ( BOOST_PP_ENUM_PARAMS(n, p) ); \ } #include BOOST_PP_LOCAL_ITERATE() What am I doing wrong? -Jason

3 3

typeof compilers support expectation
by Arkadiy Vertleyb 14 Sep '05

14 Sep '05

Hi All, How important it is for the Typeof library to support the following compilers: gcc 2.95 sunpro borland dmc? It looks like these four would represent most significant problems in porting. Regards, Arkadiy

1 0

Re: [boost] Checked Integral Class
by Matt Doyle 14 Sep '05

14 Sep '05

I have pretty much the same template in my lib with the main exceptions being that, where possible, I statically assert as well, and I (sort of) allow for non-integral types (run time only). TBoundValue<typename RT, typename DT, RT min, RT max> I would love to figure out how to trick the compiler into evaluating a floating point, non-type argument but so far I haven't found it (a few ideas though :) Anyway, if there's interest in it I'd be willing to work together with you on it and merge our approaches together. Matt > I've written a template class to hold a range of valid > integral values. My > intent was to mimic Ada's ability to define a type like this: > > type SmallInt is range -10 .. 10; > > One can then declare objects of this type and any subsequent > assignment that > violated this range constraint woud throw an exception. > > I have built a C++ template class that does the same thing: > > template<typename T, T min, T max> > struct CheckedIntegralValue > > To define a type that can hold the same range as the example above: > > typedef CheckedIntegralValue<int, -10, 10> SmallIntType; > > SmallIntType i = -10;//OK > SmallIntType i2 = -100;//Will throw an exception at run-time > for value > out-of-range > > I won't include the whole thing here, but I can do so if > there is enough > interest. I have defined most of the operators one needs to > use this type > just as one would use a 'normal' integer. > > Would anyone be interested in something like this in the > Boost libraries? > > Regards, > > Dan McLeran > > Scanned by Fortigate {X3BTB534}

3 3

Re: [boost] Checked Integral Class
by Matt Doyle 14 Sep '05

14 Sep '05

> > I also do some static assertions and I was thinking of adding static > functionality to add, multiply, divide, etc. at compile time. > One could do > this if one knew the lhs & rhs values at compile-time. > > What's the "typename DT" template parameter for? > RT = range type, and DT = data type. That's what I meant by "sort of" for the floats. When I was able to do my math with ints it worked great but when I had to switch to doubles that's the closest I got. Bounding the floating point value against integral limits. >Let me clean up what I've got and I'll send it to you via email with a small >test program and we can kick it around a while. O.K. I'll clean mine up too. I also want to look at what Cromwell & Peder are working on. I really like the idea of performing as much of the math as possible at compile time. There-in lies part of the tricky bit though, if it can't be resolved at compile time it needs to revert to a run-time operation. Matt Scanned by Fortigate {X3BTB534}

1 0

[metamath] Error and question about function calls
by Chris Weed 14 Sep '05

14 Sep '05

Hi, I was trying to test the trigonometric functions and add an exp function in the metamath library. I am not sure how to call them. Also line 58 of string_to_double.hpp needs to be changed to the following to compile in gcc: typedef typename pow_impl<unsigned_exponent>::template apply<T>::type positive_pow; Thanks, Chris

2 3

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

14 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-14T17:39:14Z 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… 589 failures in 12 libraries: concept_check (18) foreach (1) graph (10) math (3) mpl (1) multi_index (1) numeric/ublas (1) random (1) range (3) serialization (539) thread (8) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux gcc-4.0.1-linux dag_longest_paths: gcc-3.4.4-linux gcc-4.0.1-linux dijkstra_cc: gcc-3.4.4-linux gcc-4.0.1-linux dijkstra_heap_performance: gcc-3.4.4-linux gcc-4.0.1-linux relaxed_heap_test: gcc-3.4.4-linux gcc-4.0.1-linux |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_serialization: intel-win32-9_0 |numeric/ublas| test2: intel-9.0-linux |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_array_binary_archive: cw-9_5-darwin vc-7_1 test_array_binary_archive_dll: cw-9_5-darwin vc-7_1 test_array_text_archive: cw-9_5-darwin vc-7_1 test_array_text_archive_dll: vc-7_1 test_array_text_warchive: cw-9_5-darwin vc-7_1 test_array_text_warchive_dll: mingw-3_4_2 vc-7_1 test_array_xml_archive: cw-9_5-darwin vc-7_1 test_array_xml_archive_dll: vc-7_1 test_array_xml_warchive: cw-9_5-darwin vc-7_1 test_array_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_binary_binary_archive: vc-7_1 test_binary_binary_archive_dll: vc-7_1 test_binary_text_archive: vc-7_1 test_binary_text_archive_dll: vc-7_1 test_binary_text_warchive: vc-7_1 test_binary_text_warchive_dll: mingw-3_4_2 vc-7_1 test_binary_xml_archive: vc-7_1 test_binary_xml_archive_dll: vc-7_1 test_binary_xml_warchive: vc-7_1 test_binary_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_class_info_load_binary_archive: vc-7_1 test_class_info_load_binary_archive_dll: vc-7_1 test_class_info_load_text_archive: vc-7_1 test_class_info_load_text_archive_dll: vc-7_1 test_class_info_load_text_warchive: vc-7_1 test_class_info_load_text_warchive_dll: mingw-3_4_2 vc-7_1 test_class_info_load_xml_archive: vc-7_1 test_class_info_load_xml_archive_dll: vc-7_1 test_class_info_load_xml_warchive: vc-7_1 test_class_info_load_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_class_info_save_binary_archive: vc-7_1 test_class_info_save_binary_archive_dll: vc-7_1 test_class_info_save_text_archive: vc-7_1 test_class_info_save_text_archive_dll: vc-7_1 test_class_info_save_text_warchive: vc-7_1 test_class_info_save_text_warchive_dll: mingw-3_4_2 vc-7_1 test_class_info_save_xml_archive: vc-7_1 test_class_info_save_xml_archive_dll: vc-7_1 test_class_info_save_xml_warchive: vc-7_1 test_class_info_save_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_contained_class_binary_archive: vc-7_1 test_contained_class_binary_archive_dll: vc-7_1 test_contained_class_text_archive: vc-7_1 test_contained_class_text_archive_dll: vc-7_1 test_contained_class_text_warchive: vc-7_1 test_contained_class_text_warchive_dll: mingw-3_4_2 vc-7_1 test_contained_class_xml_archive: vc-7_1 test_contained_class_xml_archive_dll: vc-7_1 test_contained_class_xml_warchive: vc-7_1 test_contained_class_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_cyclic_ptrs_binary_archive: vc-7_1 test_cyclic_ptrs_binary_archive_dll: vc-7_1 test_cyclic_ptrs_text_archive: vc-7_1 test_cyclic_ptrs_text_archive_dll: vc-7_1 test_cyclic_ptrs_text_warchive: vc-7_1 test_cyclic_ptrs_text_warchive_dll: mingw-3_4_2 vc-7_1 test_cyclic_ptrs_xml_archive: vc-7_1 test_cyclic_ptrs_xml_archive_dll: vc-7_1 test_cyclic_ptrs_xml_warchive: vc-7_1 test_cyclic_ptrs_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_delete_pointer_binary_archive: vc-7_1 test_delete_pointer_binary_archive_dll: vc-7_1 test_delete_pointer_text_archive: vc-7_1 test_delete_pointer_text_archive_dll: vc-7_1 test_delete_pointer_text_warchive: vc-7_1 test_delete_pointer_text_warchive_dll: mingw-3_4_2 vc-7_1 test_delete_pointer_xml_archive: vc-7_1 test_delete_pointer_xml_archive_dll: vc-7_1 test_delete_pointer_xml_warchive: vc-7_1 test_delete_pointer_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_deque_binary_archive: vc-7_1 test_deque_binary_archive_dll: vc-7_1 test_deque_text_archive: vc-7_1 test_deque_text_archive_dll: vc-7_1 test_deque_text_warchive: vc-7_1 test_deque_text_warchive_dll: mingw-3_4_2 vc-7_1 test_deque_xml_archive: vc-7_1 test_deque_xml_archive_dll: vc-7_1 test_deque_xml_warchive: vc-7_1 test_deque_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_binary_archive: vc-7_1 test_derived_binary_archive_dll: vc-7_1 test_derived_class_binary_archive: vc-7_1 test_derived_class_binary_archive_dll: vc-7_1 test_derived_class_ptr_binary_archive: vc-7_1 test_derived_class_ptr_binary_archive_dll: vc-7_1 test_derived_class_ptr_text_archive: vc-7_1 test_derived_class_ptr_text_archive_dll: vc-7_1 test_derived_class_ptr_text_warchive: vc-7_1 test_derived_class_ptr_text_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_class_ptr_xml_archive: vc-7_1 test_derived_class_ptr_xml_archive_dll: vc-7_1 test_derived_class_ptr_xml_warchive: vc-7_1 test_derived_class_ptr_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_class_text_archive: vc-7_1 test_derived_class_text_archive_dll: vc-7_1 test_derived_class_text_warchive: vc-7_1 test_derived_class_text_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_class_xml_archive: vc-7_1 test_derived_class_xml_archive_dll: vc-7_1 test_derived_class_xml_warchive: vc-7_1 test_derived_class_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_text_archive: vc-7_1 test_derived_text_archive_dll: vc-7_1 test_derived_text_warchive: vc-7_1 test_derived_text_warchive_dll: mingw-3_4_2 vc-7_1 test_derived_xml_archive: vc-7_1 test_derived_xml_archive_dll: vc-7_1 test_derived_xml_warchive: vc-7_1 test_derived_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_diamond_binary_archive: vc-7_1 test_diamond_binary_archive_dll: vc-7_1 test_diamond_text_archive: vc-7_1 test_diamond_text_archive_dll: vc-7_1 test_diamond_text_warchive: vc-7_1 test_diamond_text_warchive_dll: mingw-3_4_2 vc-7_1 test_diamond_xml_archive: vc-7_1 test_diamond_xml_archive_dll: vc-7_1 test_diamond_xml_warchive: vc-7_1 test_diamond_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_exported_binary_archive: vc-6_5 vc-7_1 test_exported_binary_archive_dll: vc-6_5 vc-7_1 test_exported_text_archive: vc-6_5 vc-7_1 test_exported_text_archive_dll: vc-6_5 vc-7_1 test_exported_text_warchive: vc-6_5 vc-7_1 test_exported_text_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_exported_xml_archive: vc-6_5 vc-7_1 test_exported_xml_archive_dll: vc-6_5 vc-7_1 test_exported_xml_warchive: vc-6_5 vc-7_1 test_exported_xml_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_list_binary_archive: vc-7_1 test_list_binary_archive_dll: vc-7_1 test_list_ptrs_binary_archive: vc-7_1 test_list_ptrs_binary_archive_dll: vc-7_1 test_list_ptrs_text_archive: vc-7_1 test_list_ptrs_text_archive_dll: vc-7_1 test_list_ptrs_text_warchive: vc-7_1 test_list_ptrs_text_warchive_dll: mingw-3_4_2 vc-7_1 test_list_ptrs_xml_archive: vc-7_1 test_list_ptrs_xml_archive_dll: vc-7_1 test_list_ptrs_xml_warchive: vc-7_1 test_list_ptrs_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_list_text_archive: vc-7_1 test_list_text_archive_dll: vc-7_1 test_list_text_warchive: vc-7_1 test_list_text_warchive_dll: mingw-3_4_2 vc-7_1 test_list_xml_archive: vc-7_1 test_list_xml_archive_dll: vc-7_1 test_list_xml_warchive: vc-7_1 test_list_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_map_binary_archive: vc-7_1 test_map_binary_archive_dll: vc-7_1 test_map_text_archive: vc-7_1 test_map_text_archive_dll: vc-7_1 test_map_text_warchive: vc-7_1 test_map_text_warchive_dll: mingw-3_4_2 vc-7_1 test_map_xml_archive: vc-6_5 vc-7_0 vc-7_1 test_map_xml_archive_dll: vc-6_5 vc-7_0 vc-7_1 test_map_xml_warchive: vc-6_5 vc-7_0 vc-7_1 test_map_xml_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_0 vc-7_1 test_mi_binary_archive: vc-7_1 test_mi_binary_archive_dll: vc-7_1 test_mi_text_archive: vc-7_1 test_mi_text_archive_dll: vc-7_1 test_mi_text_warchive: vc-7_1 test_mi_text_warchive_dll: mingw-3_4_2 vc-7_1 test_mi_xml_archive: vc-7_1 test_mi_xml_archive_dll: vc-7_1 test_mi_xml_warchive: vc-7_1 test_mi_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_multiple_ptrs_binary_archive: vc-7_1 test_multiple_ptrs_binary_archive_dll: vc-7_1 test_multiple_ptrs_text_archive: vc-7_1 test_multiple_ptrs_text_archive_dll: vc-7_1 test_multiple_ptrs_text_warchive: vc-7_1 test_multiple_ptrs_text_warchive_dll: mingw-3_4_2 vc-7_1 test_multiple_ptrs_xml_archive: vc-7_1 test_multiple_ptrs_xml_archive_dll: vc-7_1 test_multiple_ptrs_xml_warchive: vc-7_1 test_multiple_ptrs_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_no_rtti_binary_archive: vc-6_5 vc-7_1 test_no_rtti_binary_archive_dll: vc-6_5 vc-7_1 test_no_rtti_text_archive: vc-6_5 vc-7_1 test_no_rtti_text_archive_dll: vc-6_5 vc-7_1 test_no_rtti_text_warchive: vc-6_5 vc-7_1 test_no_rtti_text_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_no_rtti_xml_archive: vc-6_5 vc-7_1 test_no_rtti_xml_archive_dll: vc-6_5 vc-7_1 test_no_rtti_xml_warchive: vc-6_5 vc-7_1 test_no_rtti_xml_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_non_default_ctor2_binary_archive: vc-7_1 test_non_default_ctor2_binary_archive_dll: vc-7_1 test_non_default_ctor2_text_archive: vc-7_1 test_non_default_ctor2_text_archive_dll: vc-7_1 test_non_default_ctor2_text_warchive: vc-7_1 test_non_default_ctor2_text_warchive_dll: mingw-3_4_2 vc-7_1 test_non_default_ctor2_xml_archive: vc-7_1 test_non_default_ctor2_xml_archive_dll: vc-7_1 test_non_default_ctor2_xml_warchive: vc-7_1 test_non_default_ctor2_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_non_default_ctor_binary_archive: vc-7_1 test_non_default_ctor_binary_archive_dll: vc-7_1 test_non_default_ctor_text_archive: vc-7_1 test_non_default_ctor_text_archive_dll: vc-7_1 test_non_default_ctor_text_warchive: vc-7_1 test_non_default_ctor_text_warchive_dll: mingw-3_4_2 vc-7_1 test_non_default_ctor_xml_archive: vc-7_1 test_non_default_ctor_xml_archive_dll: vc-7_1 test_non_default_ctor_xml_warchive: vc-7_1 test_non_default_ctor_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_non_intrusive_binary_archive: vc-7_1 test_non_intrusive_binary_archive_dll: vc-7_1 test_non_intrusive_text_archive: vc-7_1 test_non_intrusive_text_archive_dll: vc-7_1 test_non_intrusive_text_warchive: vc-7_1 test_non_intrusive_text_warchive_dll: mingw-3_4_2 vc-7_1 test_non_intrusive_xml_archive: vc-7_1 test_non_intrusive_xml_archive_dll: vc-7_1 test_non_intrusive_xml_warchive: vc-7_1 test_non_intrusive_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_null_ptr_binary_archive: vc-7_1 test_null_ptr_binary_archive_dll: vc-7_1 test_null_ptr_text_archive: vc-7_1 test_null_ptr_text_archive_dll: vc-7_1 test_null_ptr_text_warchive: vc-7_1 test_null_ptr_text_warchive_dll: mingw-3_4_2 vc-7_1 test_null_ptr_xml_archive: vc-7_1 test_null_ptr_xml_archive_dll: vc-7_1 test_null_ptr_xml_warchive: vc-7_1 test_null_ptr_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_nvp_binary_archive: vc-7_1 test_nvp_binary_archive_dll: vc-7_1 test_nvp_text_archive: vc-7_1 test_nvp_text_archive_dll: vc-7_1 test_nvp_text_warchive: vc-7_1 test_nvp_text_warchive_dll: mingw-3_4_2 vc-7_1 test_nvp_xml_archive: vc-7_1 test_nvp_xml_archive_dll: vc-7_1 test_nvp_xml_warchive: vc-7_1 test_nvp_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_object_binary_archive: vc-7_1 test_object_binary_archive_dll: vc-7_1 test_object_text_archive: vc-7_1 test_object_text_archive_dll: vc-7_1 test_object_text_warchive: vc-7_1 test_object_text_warchive_dll: mingw-3_4_2 vc-7_1 test_object_xml_archive: vc-7_1 test_object_xml_archive_dll: vc-7_1 test_object_xml_warchive: vc-7_1 test_object_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_optional_binary_archive: vc-7_1 test_optional_binary_archive_dll: vc-7_1 test_optional_text_archive: vc-7_1 test_optional_text_archive_dll: vc-7_1 test_optional_text_warchive: vc-7_1 test_optional_text_warchive_dll: mingw-3_4_2 vc-7_1 test_optional_xml_archive: vc-7_1 test_optional_xml_archive_dll: vc-7_1 test_optional_xml_warchive: vc-7_1 test_optional_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_polymorphic_text_warchive_dll: mingw-3_4_2 test_polymorphic_xml_warchive_dll: mingw-3_4_2 test_primitive_binary_archive: vc-7_1 test_primitive_binary_archive_dll: vc-7_1 test_primitive_text_archive: vc-7_1 test_primitive_text_archive_dll: vc-7_1 test_primitive_text_warchive: vc-7_1 test_primitive_text_warchive_dll: mingw-3_4_2 vc-7_1 test_primitive_xml_archive: vc-7_1 test_primitive_xml_archive_dll: vc-7_1 test_primitive_xml_warchive: vc-7_1 test_primitive_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_recursion_binary_archive: vc-7_1 test_recursion_binary_archive_dll: vc-7_1 test_recursion_text_archive: vc-7_1 test_recursion_text_archive_dll: vc-7_1 test_recursion_text_warchive: vc-7_1 test_recursion_text_warchive_dll: mingw-3_4_2 vc-7_1 test_recursion_xml_archive: vc-7_1 test_recursion_xml_archive_dll: vc-7_1 test_recursion_xml_warchive: vc-7_1 test_recursion_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_registered_binary_archive: vc-7_1 test_registered_binary_archive_dll: vc-7_1 test_registered_text_archive: vc-7_1 test_registered_text_archive_dll: vc-7_1 test_registered_text_warchive: vc-7_1 test_registered_text_warchive_dll: mingw-3_4_2 vc-7_1 test_registered_xml_archive: vc-7_1 test_registered_xml_archive_dll: vc-7_1 test_registered_xml_warchive: vc-7_1 test_registered_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_set_binary_archive: vc-7_1 test_set_binary_archive_dll: vc-7_1 test_set_text_archive: vc-7_1 test_set_text_archive_dll: vc-7_1 test_set_text_warchive: vc-7_1 test_set_text_warchive_dll: mingw-3_4_2 vc-7_1 test_set_xml_archive: vc-7_1 test_set_xml_archive_dll: vc-7_1 test_set_xml_warchive: vc-7_1 test_set_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_binary_archive_dll: vc-6_5 vc-7_1 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_text_archive_dll: vc-6_5 vc-7_1 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_text_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_xml_archive_dll: vc-6_5 vc-7_1 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_xml_warchive_dll: mingw-3_4_2 vc-6_5 vc-7_1 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_warchive_dll: borland-5_6_4 mingw-3_4_2 vc-6_5 vc-7_1 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_xml_warchive_dll: borland-5_6_4 mingw-3_4_2 vc-6_5 vc-7_1 test_simple_class_binary_archive: vc-7_1 test_simple_class_binary_archive_dll: vc-7_1 test_simple_class_ptr_binary_archive: vc-7_1 test_simple_class_ptr_binary_archive_dll: vc-7_1 test_simple_class_ptr_text_archive: vc-7_1 test_simple_class_ptr_text_archive_dll: vc-7_1 test_simple_class_ptr_text_warchive: vc-7_1 test_simple_class_ptr_text_warchive_dll: mingw-3_4_2 vc-7_1 test_simple_class_ptr_xml_archive: vc-7_1 test_simple_class_ptr_xml_archive_dll: vc-7_1 test_simple_class_ptr_xml_warchive: vc-7_1 test_simple_class_ptr_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_simple_class_text_archive: vc-7_1 test_simple_class_text_archive_dll: vc-7_1 test_simple_class_text_warchive: vc-7_1 test_simple_class_text_warchive_dll: mingw-3_4_2 vc-7_1 test_simple_class_xml_archive: vc-7_1 test_simple_class_xml_archive_dll: vc-7_1 test_simple_class_xml_warchive: vc-7_1 test_simple_class_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_split_binary_archive: vc-7_1 test_split_binary_archive_dll: vc-7_1 test_split_text_archive: vc-7_1 test_split_text_archive_dll: vc-7_1 test_split_text_warchive: vc-7_1 test_split_text_warchive_dll: mingw-3_4_2 vc-7_1 test_split_xml_archive: vc-7_1 test_split_xml_archive_dll: vc-7_1 test_split_xml_warchive: vc-7_1 test_split_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_tracking_binary_archive: vc-7_1 test_tracking_binary_archive_dll: vc-7_1 test_tracking_text_archive: vc-7_1 test_tracking_text_archive_dll: vc-7_1 test_tracking_text_warchive: vc-7_1 test_tracking_text_warchive_dll: mingw-3_4_2 vc-7_1 test_tracking_xml_archive: vc-7_1 test_tracking_xml_archive_dll: vc-7_1 test_tracking_xml_warchive: vc-7_1 test_tracking_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_unregistered_binary_archive: vc-7_1 test_unregistered_binary_archive_dll: vc-7_1 test_unregistered_text_archive: vc-7_1 test_unregistered_text_archive_dll: vc-7_1 test_unregistered_text_warchive: vc-7_1 test_unregistered_text_warchive_dll: mingw-3_4_2 vc-7_1 test_unregistered_xml_archive: vc-7_1 test_unregistered_xml_archive_dll: vc-7_1 test_unregistered_xml_warchive: vc-7_1 test_unregistered_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_variant_binary_archive: vc-7_1 test_variant_binary_archive_dll: vc-7_1 test_variant_text_archive: vc-7_1 test_variant_text_archive_dll: vc-7_1 test_variant_text_warchive: vc-7_1 test_variant_text_warchive_dll: mingw-3_4_2 vc-7_1 test_variant_xml_archive: vc-7_1 test_variant_xml_archive_dll: vc-7_1 test_variant_xml_warchive: vc-7_1 test_variant_xml_warchive_dll: mingw-3_4_2 vc-7_1 test_vector_binary_archive: vc-7_1 test_vector_binary_archive_dll: vc-7_1 test_vector_text_archive: vc-7_1 test_vector_text_archive_dll: vc-7_1 test_vector_text_warchive: vc-7_1 test_vector_text_warchive_dll: mingw-3_4_2 vc-7_1 test_vector_xml_archive: vc-7_1 test_vector_xml_archive_dll: vc-7_1 test_vector_xml_warchive: vc-7_1 test_vector_xml_warchive_dll: mingw-3_4_2 vc-7_1 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

1 0

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

14 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-14T05: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 Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 263 failures in 17 libraries: algorithm/string (1) concept_check (14) date_time (5) filesystem (8) foreach (7) graph (7) iostreams (1) math (6) mpl (2) parameter (18) python (1) regex (36) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |algorithm/string| regex: gcc-3_3-darwin |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 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: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: 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| biconnected_components_test: 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 |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 efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-4_0-darwin msvc 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: cw-9_4 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 intel-win32-9_0 function_emulation: cw-9_4 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 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 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 intel-win32-9_0 function_ref_emulation: cw-9_4 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 intel-win32-9_0 lvalue_emulation: cw-9_4 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 intel-win32-9_0 msvc member_function_emulation: cw-9_4 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 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 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 intel-win32-9_0 template_tpl_emulation: cw-9_4 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 intel-win32-9_0 msvc template_type_emulation: cw-9_4 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 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 intel-9.0-linux

1 0

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

14 Sep '05

<html> <head> <meta http-equiv="refresh" content="1; url=issues-email.txt"> </head> <body> Update in progress (building archive index, done in approximately 6 seconds), please wait... </body> </html>

3 2

Re: [boost] Scons users?
by David Gruener 14 Sep '05

14 Sep '05

David Abrahams wrote: > ... chosen Scons over Boost.Build. > It would be useful for us to understand some of the > reasons why, if some of you wouldn't mind letting us know. At the point of the decision against bbs times ago the poor documentation and the unclear state of usability of bbsv2 were reasons against bbs. Using an existing powerfull language as base for a build system is unbeatable concerning expressiveness and extensibility: You can hack and extend SCons in any way with ease to get what you want. A litle bad aftertaste was and is that SCons still performs poorly in real-word projects. 0.02 $

1 0

[program_options] undefined references
by Richard Hadsell 14 Sep '05

14 Sep '05

We are using Boost 1.33.0 with g++ 3.4.4 on an Opteron machine. I compiled .a archive libraries for our users to link to. The compile options we normally build our software with are '-march=opteron -m64 -ansi -mieee-fp -fPIC' along with '-O2' or '-g'. One of our users ran into this problem trying to link his program (I shortened some of our names): ...: In function `bssProgramOptions::parse_config_file(char const*)': x.cc:252: undefined reference to `boost::program_options::basic_parsed_options<char> boost::program_options::parse_config_file<char>(std::basic_istream<char, std::char_traits<char> >&, boost::program_options::options_description const&)' ...(.gnu.linkonce.t._ZN5boost15program_options25basic_command_line_parserIcEC1ERKSt6vectorISsSaISsEE+0x27): In function `boost::program_options::basic_command_line_parser<char>::basic_command_line_parser(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)': .../boost/program_options/detail/parsers.hpp:32: undefined reference to `boost::program_options::detail::cmdline::cmdline(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)' ...(.gnu.linkonce.t._ZN5boost15program_options25basic_command_line_parserIcE7optionsERKNS0_19options_descriptionE+0x19): In function `boost::program_options::basic_command_line_parser<char>::options(boost::program_options::options_description const&)': .../boost/program_options/detail/parsers.hpp:49: undefined reference to `boost::program_options::detail::cmdline::set_options_description(boost::program_options::options_description const&)' ...(.gnu.linkonce.t._ZN5boost15program_options25basic_command_line_parserIcE10positionalERKNS0_30positional_options_descriptionE+0x19): In function `boost::program_options::basic_command_line_parser<char>::positional(boost::program_options::positional_options_description const&)': .../boost/program_options/detail/parsers.hpp:59: undefined reference to `boost::program_options::detail::cmdline::set_positional_options(boost::program_options::positional_options_description const&)' ...(.gnu.linkonce.t._ZN5boost15program_options25basic_command_line_parserIcE5styleEi+0x17): In function `boost::program_options::basic_command_line_parser<char>::style(int)': .../boost/program_options/detail/parsers.hpp:67: undefined reference to `boost::program_options::detail::cmdline::style(int)' ...(.gnu.linkonce.t._ZN5boost15program_options25basic_command_line_parserIcE3runEv+0x2b): In function `boost::program_options::basic_command_line_parser<char>::run()': .../boost/program_options/detail/parsers.hpp:84: undefined reference to `boost::program_options::detail::cmdline::run()' ...(.gnu.linkonce.t._ZN5boost15program_options25basic_command_line_parserIcEC1EiPPc+0x4e): In function `boost::program_options::basic_command_line_parser<char>::basic_command_line_parser(int, char**)': .../boost/program_options/detail/parsers.hpp:42: undefined reference to `boost::program_options::detail::cmdline::cmdline(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)' collect2: ld returned 1 exit status Does anyone recognize these symptoms? -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

1 1

[singleton] call_once
by Jason Hise 14 Sep '05

14 Sep '05

How does call_once work? Does it maintain a separate mutex for each unique function pointer passed in, or is there only one global mutex shared by all calls to call_once? In other words, can call_once(foo, flag) block call_once(bar, flag2)? -Jason

4 11

[thread rewite]
by John Maddock 14 Sep '05

14 Sep '05

Matt, Anthony, You are making any changes to the thread library on a cvs branch right? We aim to keep the cvs HEAD in as close to a release-ready state as we can, so new / experimental code shouldn't be in the HEAD right now. I'm asking because we already have some regressions caused by changes to call_once in the cvs HEAD: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/thread… Thanks, John.

2 3

[thread] explicit constructor in thread
by Matt Hurd 14 Sep '05

14 Sep '05

any particular reason why the function sig accepted is function < void ( void ) > instead of function < void ( void * ) > which you might deduce as more complete for at least these four platforms: thread function signatures ( noted in ACE ) posix = function< void * ( void * ) > win32 = function < DWORD ( void * ) > vxworks without pthreads = function < int (...) > // if such a thing were possible?? pSoS = function < void (void *) > any other examples or thoughts ? matt

2 1

Re: [boost] Interest in an arbitrary precision library?
by Martin Bonner 14 Sep '05

14 Sep '05

----Original Message---- From: Daryle Walker [mailto:darylew@hotmail.com] Sent: 14 September 2005 07:12 To: Boost mailing list Subject: Re: [boost] Interest in an arbitrary precision library? > On 9/13/05 7:28 AM, "Andy Little" <andy(a)servocomm.freeserve.co.uk> > wrote: > >> "Daryle Walker" <darylew(a)hotmail.com> wrote >> >>> OK. When you say "arbitrary precision," you mean that a precision >>> limit must be set (at run-time) before an operation. Most people >>> use "arbitrary precision" to mean unlimited precision, not your >>> "run-time cut-off" precision. >> >> Are there really libraries that have unlimited precision? >> What happens when the result of a computation is irrational? > > You can't store it conventionally, since such numbers would need an > infinite amount of memory. You would just give up and have to define > some sort of rounding/cut-off philosophy. As another poster said, > you could store the irrational components of a number with some sort > of formula (but only for algebraically irrational numbers, not > transcendentally irrational numbers). Why only for algebraiclly irrational numbers? There is no reason (in principle) that the representation of an irrational shouldn't include trig / hyperbolic / bessel functions of irrationals, or even definite integrals. Of course, at this point you get close to rewriting a chunk of Matlab or Mathematica. On the other hand, simplifying (sqrt(5)-sqrt(3))*(sqrt(5)+sqrt(3)) to exactly 2 is quite a challenge too (and if you don't then the unlimited precision representation doesn't really buy you anything). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

New flag to add to Linux DEBUG mode compilation
by Kevin Wheatley 14 Sep '05

14 Sep '05

1 1

[Review] Reminder xpressive formal review
by Thomas Witt 14 Sep '05

14 Sep '05

Hi, This is to remind everyone of the formal review of Eric Niebler's xpressive library. The review period is scheduled to end Sunday, September 18. I want to especially point out the xpressive is not just another 'regex' library. It goes beyond the scope of regular regex (no pun intended) engines. Here is what Eric has to say: "Although xpressive's primitives are regex-ish in nature, xpressive is far more than just a regular expression engine. It is a pattern matching engine with the power of context-free grammars. By allowing you to embed one pattern in another by reference, xpressive lets you find patterns in data that are recursive in nature. Problems that are intractible with "classic" regular expressions, such as matching balanced nested parentheses or matching XML tags, are simple with xpressive. So xpressive is more rightly thought of as a context-free grammar engine with exhaustive backtracking. The goal is to provide one framework and one set of pattern matching primitives that scales from simple strstr-style grepping, through ordinary regexing, all the way to full-blown parsing." For a glimpse of what xpressive can do look at "Grammars and Nested Matches" here: http://tinyurl.com/d7637 This link takes you to the online docs. The full sources and docs (also in PDF) are available here: http://tinyurl.com/8fean Thomas Review Manager xpressive Thomas Witt witt(a)acm.org

1 0

[regression testing] /libs/numeric/conversion/test/converter_test
by Matt Hurd 14 Sep '05

14 Sep '05

suse linux x86_64 gcc 4.0.1 continues to fail for the following test: /libs/numeric/conversion/test/converter_test Is there a standard way parameterise the python script to avoid this failure. Others seem to run the tests fine looking at the meta-comm site. It is just my zomojo config that fails. regards, matt. matt.hurd(a)zomojo.com _________________________________________________ tail of bjam.log... gcc is in an endless compile MkDir1 /zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test mkdir "/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test" MkDir1 /zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc mkdir "/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc" MkDir1 /zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug mkdir "/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug" gcc-C++-action /zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug/converter_test.o set -e "g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -I"/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test" -I "/zomojo/regression_boost/boost" -o "/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug/converter_test.o" "/zomojo/regression_boost/boost/libs/numeric/conversion/test/converter_test.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "/zomojo/regression_boost/results/bin/boost/libs/numeric/conversion/test/converter_test.test/gcc/debug/converter_test.o"

1 0

Re: [boost] [Review] xpressive - Doc comments
by David Abrahams 14 Sep '05

14 Sep '05

Joel de Guzman <joel(a)boost-consulting.com> writes: > David Abrahams wrote: >> This may have more to do with boostbook/quickbook than with xpressive, but in my >> Windows XP FireFox browser, it appears that every place inline code is >> followed by regular text, there is no space separating them. Spaces >> also seem to be missing in a few other places, e.g. "usingnamespace" >> can be seen on >> http://boost-consulting.com/projects/xpressive/xpressive/user_s_guide.html#…, >> as can "representationof" ("representation" is in italics). So this >> probably applies to all style changes. > > I'm almost sure that I already fixed that a few days ago. Ok, > lemme check... > > Ok, I just confirmed that this bug has been fixed. Eric, please run > the docs using the latest QuickBook from Boost HEAD CVS. > >> Also, the full justification of text is difficult to read. I don't >> think web browsers are smart enough about formatting to make that >> legible, at least not at the normal smallish text sizes. > > Hrmmm. Very subjective. I feel the opposite. Full justification is > better for smaller fonts than bigger fonts because there are more > spaces to allocate and divide. The problem is when there are few > spaces in between text. Well, I don't know the reasons, but Firefox does a fairly poor job of it, at least compared to LaTeX. Well, maybe my biggest complaint has to do with tables, as in http://boost-consulting.com/projects/xpressive/xpressive/creating_a_regex_o… LaTeX does a bad job there, too :) Can you turn off full justification in tables? >> Also, I think the abbrev "parens" should be changed to the word >> "parentheses" :) > > In QuickBook docs? In xpressive? The xpressive docs. But QuickBook too, if you use "parens" there. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[serialization] cannot build with BOOST_NO_EXCEPTIONS defined
by JOAQUIN LOPEZ MU?Z 13 Sep '05

13 Sep '05

Boost.Serialization tries to be BOOST_NO_EXCEPTIONS-compatible, as it uses boost::throw_exception to throw, but alas the lib does not build when setting the macro, since archive_exception (boost/archive/archive_exception.hpp) is only defined ifndef(BOOST_NO_EXCEPTIONS), so that expressions like boost::throw_exception( archive_exception(archive_exception::unregistered_class)); fail to compile. AFAICS it'd only take for archive_exception to be defined in all cases. Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

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

13 Sep '05

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Martes, Septiembre 13, 2005 6:10 pm Asunto: Re: [boost] [serialization] No Reply? > This is quite interesting to me. Its going to take a little time > to > consider with the attention it deserves. > > Robert Ramey > > JOAQUIN LOPEZ MU?Z wrote: > > ----- 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 above doesn't seem right to me. I don't see its necessary here > an it > makes the concept of serializable and archive circular. I believe > that the > inductive definition below - and currently in the document (more or > less) > defines the concept of serializable well enough. > Hmm... yep, rethinking it, this is superfluous (yet not circular AFAICS): the validity of these expressions is guaranteed by the archive concept as you explain in your docs. Serializability has to be defined in terms of the presence of the serialize function/memfun, as you're doing now. I think there's some weak points in my proposal having to do with the relationship between "archive association" and "restored copy" --for instance, a dummy archive wih accepts iar>>t for every t and simply does nothing would be, according to the definitions, associated with any output archive, and this is clearly not what we want. I've got this thing going round my head, allow me to come back to you in a few days. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] [Review] xpressive - Doc comments
by Eric Niebler 13 Sep '05

13 Sep '05

Thomas Witt wrote: > Joel de Guzman wrote: > >> David Abrahams wrote: >> >>> This may have more to do with boostbook/quickbook than with >>> xpressive, but in my >>> Windows XP FireFox browser, it appears that every place inline code is >>> followed by regular text, there is no space separating them. Spaces >>> also seem to be missing in a few other places, e.g. "usingnamespace" >>> can be seen on >>> http://boost-consulting.com/projects/xpressive/xpressive/user_s_guide.html#…, >>> >>> as can "representationof" ("representation" is in italics). So this >>> probably applies to all style changes. >> >> >> I'm almost sure that I already fixed that a few days ago. Ok, >> lemme check... >> >> Ok, I just confirmed that this bug has been fixed. Eric, please run >> the docs using the latest QuickBook from Boost HEAD CVS. > > > Hmm... I just confirmed the bug still exists with inline code. CVS Head > of now. This seems to be related to the xml pretty printing. > > Thomas > The bug still exists, confirmed. I have disabled XML pretty printing and regenerated the docs. I've updated the download and put the clean docs at http://boost-sandbox.sf.net/libs/xpressive. (I also took the opportunity to patch a few portability issues in the code.) -- Eric Niebler Boost Consulting www.boost-consulting.com

3 5

CVS Development Status on Boost main page
by Doug Gregor 13 Sep '05

13 Sep '05

I've added the CVS Development Status at the end of the Participation section on the Boost main page. Let's keep this up-to-date so developers know what we're doing without reading the mailing list every day. Doug

1 0

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

13 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-13T18:04:22Z 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… 593 failures in 12 libraries: concept_check (18) foreach (1) graph (22) math (3) mpl (1) multi_index (1) numeric/ublas (1) random (1) range (28) serialization (506) thread (8) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: cw-8_3 gcc-3.4.4-linux gcc-4.0.1-linux gcc-4_0-darwin dag_longest_paths: cw-8_3 gcc-3.4.4-linux gcc-4.0.1-linux gcc-4_0-darwin dijkstra_cc: cw-8_3 gcc-3.4.4-linux gcc-4.0.1-linux gcc-4_0-darwin dijkstra_heap_performance: cw-8_3 gcc-3.4.4-linux gcc-4.0.1-linux gcc-4_0-darwin gursoy_atun_layout_test: cw-8_3 layout_test: cw-8_3 relaxed_heap_test: cw-8_3 gcc-3.4.4-linux gcc-4.0.1-linux gcc-4_0-darwin |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_serialization: intel-win32-9_0 |numeric/ublas| test2: intel-9.0-linux |random| random_test: gcc-3.3.6-linux |range| algorithm_example: vc-6_5 vc-6_5-stlport vc-7_0 array: vc-6_5 vc-6_5-stlport vc-7_0 const_ranges: vc-6_5 vc-6_5-stlport vc-7_0 iterator_pair: cw-8_3 gcc-4_0-darwin vc-6_5 vc-6_5-stlport vc-7_0 partial_workaround: vc-6_5 vc-6_5-stlport vc-7_0 std_container: cw-8_3 gcc-4_0-darwin vc-6_5 vc-6_5-stlport vc-7_0 string: cw-8_3 gcc-4_0-darwin vc-6_5 vc-6_5-stlport vc-7_0 sub_range: vc-6_5 |serialization| test_array_binary_archive: cw-9_5-darwin vc-7_1 test_array_binary_archive_dll: cw-9_5-darwin vc-7_1 test_array_text_archive: cw-9_5-darwin vc-7_1 test_array_text_archive_dll: vc-7_1 test_array_text_warchive: cw-9_5-darwin vc-7_1 test_array_text_warchive_dll: vc-7_1 test_array_xml_archive: cw-9_5-darwin vc-7_1 test_array_xml_archive_dll: vc-7_1 test_array_xml_warchive: cw-9_5-darwin vc-7_1 test_array_xml_warchive_dll: vc-7_1 test_binary_binary_archive: vc-7_1 test_binary_binary_archive_dll: vc-7_1 test_binary_text_archive: vc-7_1 test_binary_text_archive_dll: vc-7_1 test_binary_text_warchive: vc-7_1 test_binary_text_warchive_dll: vc-7_1 test_binary_xml_archive: vc-7_1 test_binary_xml_archive_dll: vc-7_1 test_binary_xml_warchive: vc-7_1 test_binary_xml_warchive_dll: vc-7_1 test_class_info_load_binary_archive: vc-7_1 test_class_info_load_binary_archive_dll: vc-7_1 test_class_info_load_text_archive: vc-7_1 test_class_info_load_text_archive_dll: vc-7_1 test_class_info_load_text_warchive: vc-7_1 test_class_info_load_text_warchive_dll: vc-7_1 test_class_info_load_xml_archive: vc-7_1 test_class_info_load_xml_archive_dll: vc-7_1 test_class_info_load_xml_warchive: vc-7_1 test_class_info_load_xml_warchive_dll: vc-7_1 test_class_info_save_binary_archive: vc-7_1 test_class_info_save_binary_archive_dll: vc-7_1 test_class_info_save_text_archive: vc-7_1 test_class_info_save_text_archive_dll: vc-7_1 test_class_info_save_text_warchive: vc-7_1 test_class_info_save_text_warchive_dll: vc-7_1 test_class_info_save_xml_archive: vc-7_1 test_class_info_save_xml_archive_dll: vc-7_1 test_class_info_save_xml_warchive: vc-7_1 test_class_info_save_xml_warchive_dll: vc-7_1 test_contained_class_binary_archive: vc-7_1 test_contained_class_binary_archive_dll: vc-7_1 test_contained_class_text_archive: vc-7_1 test_contained_class_text_archive_dll: vc-7_1 test_contained_class_text_warchive: vc-7_1 test_contained_class_text_warchive_dll: vc-7_1 test_contained_class_xml_archive: vc-7_1 test_contained_class_xml_archive_dll: vc-7_1 test_contained_class_xml_warchive: vc-7_1 test_contained_class_xml_warchive_dll: vc-7_1 test_cyclic_ptrs_binary_archive: vc-7_1 test_cyclic_ptrs_binary_archive_dll: vc-7_1 test_cyclic_ptrs_text_archive: vc-7_1 test_cyclic_ptrs_text_archive_dll: vc-7_1 test_cyclic_ptrs_text_warchive: vc-7_1 test_cyclic_ptrs_text_warchive_dll: vc-6_5 vc-7_1 test_cyclic_ptrs_xml_archive: vc-7_1 test_cyclic_ptrs_xml_archive_dll: vc-7_1 test_cyclic_ptrs_xml_warchive: vc-7_1 test_cyclic_ptrs_xml_warchive_dll: vc-6_5 vc-7_1 test_delete_pointer_binary_archive: vc-7_1 test_delete_pointer_binary_archive_dll: vc-7_1 test_delete_pointer_text_archive: vc-7_1 test_delete_pointer_text_archive_dll: vc-7_1 test_delete_pointer_text_warchive: vc-7_1 test_delete_pointer_text_warchive_dll: vc-6_5 vc-7_1 test_delete_pointer_xml_archive: vc-7_1 test_delete_pointer_xml_archive_dll: vc-7_1 test_delete_pointer_xml_warchive: vc-7_1 test_delete_pointer_xml_warchive_dll: vc-6_5 vc-7_1 test_demo: intel-win32-8_1 test_demo_dll: borland-5_6_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: borland-5_6_4 test_demo_shared_ptr: intel-win32-8_1 test_demo_shared_ptr_dll: borland-5_6_4 test_demo_xml_dll: borland-5_6_4 test_demo_xml_load: intel-win32-8_1 test_demo_xml_load_dll: borland-5_6_4 test_demo_xml_save: intel-win32-8_1 test_demo_xml_save_dll: borland-5_6_4 test_deque_binary_archive: vc-7_1 test_deque_binary_archive_dll: vc-7_1 test_deque_text_archive: vc-7_1 test_deque_text_archive_dll: vc-7_1 test_deque_text_warchive: vc-7_1 test_deque_text_warchive_dll: vc-7_1 test_deque_xml_archive: vc-7_1 test_deque_xml_archive_dll: vc-7_1 test_deque_xml_warchive: vc-7_1 test_deque_xml_warchive_dll: vc-7_1 test_derived_binary_archive: vc-7_1 test_derived_binary_archive_dll: vc-7_1 test_derived_class_binary_archive: vc-7_1 test_derived_class_binary_archive_dll: vc-7_1 test_derived_class_ptr_binary_archive: vc-7_1 test_derived_class_ptr_binary_archive_dll: vc-7_1 test_derived_class_ptr_text_archive: vc-7_1 test_derived_class_ptr_text_archive_dll: vc-7_1 test_derived_class_ptr_text_warchive: vc-7_1 test_derived_class_ptr_text_warchive_dll: vc-6_5 vc-7_1 test_derived_class_ptr_xml_archive: vc-7_1 test_derived_class_ptr_xml_archive_dll: vc-7_1 test_derived_class_ptr_xml_warchive: vc-7_1 test_derived_class_ptr_xml_warchive_dll: vc-6_5 vc-7_1 test_derived_class_text_archive: vc-7_1 test_derived_class_text_archive_dll: vc-7_1 test_derived_class_text_warchive: vc-7_1 test_derived_class_text_warchive_dll: vc-7_1 test_derived_class_xml_archive: vc-7_1 test_derived_class_xml_archive_dll: vc-7_1 test_derived_class_xml_warchive: vc-7_1 test_derived_class_xml_warchive_dll: vc-7_1 test_derived_text_archive: vc-7_1 test_derived_text_archive_dll: vc-7_1 test_derived_text_warchive: vc-7_1 test_derived_text_warchive_dll: vc-6_5 vc-7_1 test_derived_xml_archive: vc-7_1 test_derived_xml_archive_dll: vc-7_1 test_derived_xml_warchive: vc-7_1 test_derived_xml_warchive_dll: vc-6_5 vc-7_1 test_diamond_binary_archive: vc-7_1 test_diamond_binary_archive_dll: vc-7_1 test_diamond_text_archive: vc-7_1 test_diamond_text_archive_dll: vc-7_1 test_diamond_text_warchive: vc-7_1 test_diamond_text_warchive_dll: vc-7_1 test_diamond_xml_archive: vc-7_1 test_diamond_xml_archive_dll: vc-7_1 test_diamond_xml_warchive: vc-7_1 test_diamond_xml_warchive_dll: vc-7_1 test_exported_binary_archive: vc-6_5 vc-7_1 test_exported_binary_archive_dll: vc-6_5 vc-7_1 test_exported_text_archive: vc-6_5 vc-7_1 test_exported_text_archive_dll: vc-6_5 vc-7_1 test_exported_text_warchive: vc-6_5 vc-7_1 test_exported_text_warchive_dll: vc-6_5 vc-7_1 test_exported_xml_archive: vc-6_5 vc-7_1 test_exported_xml_archive_dll: vc-6_5 vc-7_1 test_exported_xml_warchive: vc-6_5 vc-7_1 test_exported_xml_warchive_dll: vc-6_5 vc-7_1 test_list_binary_archive: vc-7_1 test_list_binary_archive_dll: vc-7_1 test_list_ptrs_binary_archive: vc-7_1 test_list_ptrs_binary_archive_dll: vc-7_1 test_list_ptrs_text_archive: vc-7_1 test_list_ptrs_text_archive_dll: vc-7_1 test_list_ptrs_text_warchive: vc-7_1 test_list_ptrs_text_warchive_dll: vc-6_5 vc-7_1 test_list_ptrs_xml_archive: vc-7_1 test_list_ptrs_xml_archive_dll: vc-7_1 test_list_ptrs_xml_warchive: vc-7_1 test_list_ptrs_xml_warchive_dll: vc-6_5 vc-7_1 test_list_text_archive: vc-7_1 test_list_text_archive_dll: vc-7_1 test_list_text_warchive: vc-7_1 test_list_text_warchive_dll: vc-7_1 test_list_xml_archive: vc-7_1 test_list_xml_archive_dll: vc-7_1 test_list_xml_warchive: vc-7_1 test_list_xml_warchive_dll: vc-7_1 test_map_binary_archive: vc-7_1 test_map_binary_archive_dll: vc-7_1 test_map_text_archive: vc-7_1 test_map_text_archive_dll: vc-7_1 test_map_text_warchive: vc-7_1 test_map_text_warchive_dll: vc-7_1 test_map_xml_archive: vc-6_5 vc-7_0 vc-7_1 test_map_xml_archive_dll: vc-6_5 vc-7_0 vc-7_1 test_map_xml_warchive: vc-6_5 vc-7_0 vc-7_1 test_map_xml_warchive_dll: vc-6_5 vc-7_0 vc-7_1 test_mi_binary_archive: vc-7_1 test_mi_binary_archive_dll: vc-7_1 test_mi_text_archive: vc-7_1 test_mi_text_archive_dll: vc-7_1 test_mi_text_warchive: vc-7_1 test_mi_text_warchive_dll: vc-7_1 test_mi_xml_archive: vc-7_1 test_mi_xml_archive_dll: vc-7_1 test_mi_xml_warchive: vc-7_1 test_mi_xml_warchive_dll: vc-7_1 test_multiple_ptrs_binary_archive: vc-7_1 test_multiple_ptrs_binary_archive_dll: vc-7_1 test_multiple_ptrs_text_archive: vc-7_1 test_multiple_ptrs_text_archive_dll: vc-7_1 test_multiple_ptrs_text_warchive: vc-7_1 test_multiple_ptrs_text_warchive_dll: vc-7_1 test_multiple_ptrs_xml_archive: vc-7_1 test_multiple_ptrs_xml_archive_dll: vc-7_1 test_multiple_ptrs_xml_warchive: vc-7_1 test_multiple_ptrs_xml_warchive_dll: vc-7_1 test_no_rtti_binary_archive: vc-6_5 vc-7_1 test_no_rtti_binary_archive_dll: vc-6_5 vc-7_1 test_no_rtti_text_archive: vc-6_5 vc-7_1 test_no_rtti_text_archive_dll: vc-6_5 vc-7_1 test_no_rtti_text_warchive: vc-6_5 vc-7_1 test_no_rtti_text_warchive_dll: vc-6_5 vc-7_1 test_no_rtti_xml_archive: vc-6_5 vc-7_1 test_no_rtti_xml_archive_dll: vc-6_5 vc-7_1 test_no_rtti_xml_warchive: vc-6_5 vc-7_1 test_no_rtti_xml_warchive_dll: vc-6_5 vc-7_1 test_non_default_ctor2_binary_archive: vc-7_1 test_non_default_ctor2_binary_archive_dll: vc-7_1 test_non_default_ctor2_text_archive: vc-7_1 test_non_default_ctor2_text_archive_dll: vc-7_1 test_non_default_ctor2_text_warchive: vc-7_1 test_non_default_ctor2_text_warchive_dll: vc-6_5 vc-7_1 test_non_default_ctor2_xml_archive: vc-7_1 test_non_default_ctor2_xml_archive_dll: vc-7_1 test_non_default_ctor2_xml_warchive: vc-7_1 test_non_default_ctor2_xml_warchive_dll: vc-6_5 vc-7_1 test_non_default_ctor_binary_archive: vc-7_1 test_non_default_ctor_binary_archive_dll: vc-7_1 test_non_default_ctor_text_archive: vc-7_1 test_non_default_ctor_text_archive_dll: vc-7_1 test_non_default_ctor_text_warchive: vc-7_1 test_non_default_ctor_text_warchive_dll: vc-6_5 vc-7_1 test_non_default_ctor_xml_archive: vc-7_1 test_non_default_ctor_xml_archive_dll: vc-7_1 test_non_default_ctor_xml_warchive: vc-7_1 test_non_default_ctor_xml_warchive_dll: vc-6_5 vc-7_1 test_non_intrusive_binary_archive: vc-7_1 test_non_intrusive_binary_archive_dll: vc-7_1 test_non_intrusive_text_archive: vc-7_1 test_non_intrusive_text_archive_dll: vc-7_1 test_non_intrusive_text_warchive: vc-7_1 test_non_intrusive_text_warchive_dll: vc-6_5 vc-7_1 test_non_intrusive_xml_archive: vc-7_1 test_non_intrusive_xml_archive_dll: vc-7_1 test_non_intrusive_xml_warchive: vc-7_1 test_non_intrusive_xml_warchive_dll: vc-6_5 vc-7_1 test_null_ptr_binary_archive: vc-7_1 test_null_ptr_binary_archive_dll: vc-7_1 test_null_ptr_text_archive: vc-7_1 test_null_ptr_text_archive_dll: vc-7_1 test_null_ptr_text_warchive: vc-7_1 test_null_ptr_text_warchive_dll: vc-6_5 vc-7_1 test_null_ptr_xml_archive: vc-7_1 test_null_ptr_xml_archive_dll: vc-7_1 test_null_ptr_xml_warchive: vc-7_1 test_null_ptr_xml_warchive_dll: vc-6_5 vc-7_1 test_nvp_binary_archive: vc-7_1 test_nvp_binary_archive_dll: vc-7_1 test_nvp_text_archive: vc-7_1 test_nvp_text_archive_dll: vc-7_1 test_nvp_text_warchive: vc-7_1 test_nvp_text_warchive_dll: vc-6_5 vc-7_1 test_nvp_xml_archive: vc-7_1 test_nvp_xml_archive_dll: vc-7_1 test_nvp_xml_warchive: vc-7_1 test_nvp_xml_warchive_dll: vc-6_5 vc-7_1 test_object_binary_archive: vc-7_1 test_object_binary_archive_dll: vc-7_1 test_object_text_archive: vc-7_1 test_object_text_archive_dll: vc-7_1 test_object_text_warchive: vc-7_1 test_object_text_warchive_dll: vc-7_1 test_object_xml_archive: vc-7_1 test_object_xml_archive_dll: vc-7_1 test_object_xml_warchive: vc-7_1 test_object_xml_warchive_dll: vc-7_1 test_optional_binary_archive: vc-7_1 test_optional_binary_archive_dll: vc-7_1 test_optional_text_archive: vc-7_1 test_optional_text_archive_dll: vc-7_1 test_optional_text_warchive: vc-7_1 test_optional_text_warchive_dll: vc-7_1 test_optional_xml_archive: vc-7_1 test_optional_xml_archive_dll: vc-7_1 test_optional_xml_warchive: vc-7_1 test_optional_xml_warchive_dll: vc-7_1 test_primitive_binary_archive: vc-7_1 test_primitive_binary_archive_dll: vc-7_1 test_primitive_text_archive: vc-7_1 test_primitive_text_archive_dll: vc-7_1 test_primitive_text_warchive: vc-7_1 test_primitive_text_warchive_dll: vc-7_1 test_primitive_xml_archive: vc-7_1 test_primitive_xml_archive_dll: vc-7_1 test_primitive_xml_warchive: vc-7_1 test_primitive_xml_warchive_dll: vc-7_1 test_recursion_binary_archive: vc-7_1 test_recursion_binary_archive_dll: vc-7_1 test_recursion_text_archive: vc-7_1 test_recursion_text_archive_dll: vc-7_1 test_recursion_text_warchive: vc-7_1 test_recursion_text_warchive_dll: vc-6_5 vc-7_1 test_recursion_xml_archive: vc-7_1 test_recursion_xml_archive_dll: vc-7_1 test_recursion_xml_warchive: vc-7_1 test_recursion_xml_warchive_dll: vc-6_5 vc-7_1 test_registered_binary_archive: vc-7_1 test_registered_binary_archive_dll: vc-7_1 test_registered_text_archive: vc-7_1 test_registered_text_archive_dll: vc-7_1 test_registered_text_warchive: vc-7_1 test_registered_text_warchive_dll: vc-6_5 vc-7_1 test_registered_xml_archive: vc-7_1 test_registered_xml_archive_dll: vc-7_1 test_registered_xml_warchive: vc-7_1 test_registered_xml_warchive_dll: vc-6_5 vc-7_1 test_set_binary_archive: vc-7_1 test_set_binary_archive_dll: vc-7_1 test_set_text_archive: vc-7_1 test_set_text_archive_dll: vc-7_1 test_set_text_warchive: vc-7_1 test_set_text_warchive_dll: vc-7_1 test_set_xml_archive: vc-7_1 test_set_xml_archive_dll: vc-7_1 test_set_xml_warchive: vc-7_1 test_set_xml_warchive_dll: vc-7_1 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_binary_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_text_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_text_warchive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_xml_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport vc-7_1 test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 vc-7_1 test_shared_ptr_xml_warchive_dll: borland-5_6_4 intel-win32-8_1 vc-6_5 vc-7_1 test_simple_class_binary_archive: vc-7_1 test_simple_class_binary_archive_dll: vc-7_1 test_simple_class_ptr_binary_archive: vc-7_1 test_simple_class_ptr_binary_archive_dll: vc-7_1 test_simple_class_ptr_text_archive: vc-7_1 test_simple_class_ptr_text_archive_dll: vc-7_1 test_simple_class_ptr_text_warchive: vc-7_1 test_simple_class_ptr_text_warchive_dll: vc-6_5 vc-7_1 test_simple_class_ptr_xml_archive: vc-7_1 test_simple_class_ptr_xml_archive_dll: vc-7_1 test_simple_class_ptr_xml_warchive: vc-7_1 test_simple_class_ptr_xml_warchive_dll: vc-6_5 vc-7_1 test_simple_class_text_archive: vc-7_1 test_simple_class_text_archive_dll: vc-7_1 test_simple_class_text_warchive: vc-7_1 test_simple_class_text_warchive_dll: vc-7_1 test_simple_class_xml_archive: vc-7_1 test_simple_class_xml_archive_dll: vc-7_1 test_simple_class_xml_warchive: vc-7_1 test_simple_class_xml_warchive_dll: vc-7_1 test_split_binary_archive: vc-7_1 test_split_binary_archive_dll: vc-7_1 test_split_text_archive: vc-7_1 test_split_text_archive_dll: vc-7_1 test_split_text_warchive: vc-7_1 test_split_text_warchive_dll: vc-7_1 test_split_xml_archive: vc-7_1 test_split_xml_archive_dll: vc-7_1 test_split_xml_warchive: vc-7_1 test_split_xml_warchive_dll: vc-7_1 test_tracking_binary_archive: vc-7_1 test_tracking_binary_archive_dll: vc-7_1 test_tracking_text_archive: vc-7_1 test_tracking_text_archive_dll: vc-7_1 test_tracking_text_warchive: vc-7_1 test_tracking_text_warchive_dll: vc-6_5 vc-7_1 test_tracking_xml_archive: vc-7_1 test_tracking_xml_archive_dll: vc-7_1 test_tracking_xml_warchive: vc-7_1 test_tracking_xml_warchive_dll: vc-6_5 vc-7_1 test_unregistered_binary_archive: vc-7_1 test_unregistered_binary_archive_dll: vc-7_1 test_unregistered_text_archive: vc-7_1 test_unregistered_text_archive_dll: vc-7_1 test_unregistered_text_warchive: vc-7_1 test_unregistered_text_warchive_dll: vc-6_5 vc-7_1 test_unregistered_xml_archive: vc-7_1 test_unregistered_xml_archive_dll: vc-7_1 test_unregistered_xml_warchive: vc-7_1 test_unregistered_xml_warchive_dll: vc-6_5 vc-7_1 test_variant_binary_archive: vc-7_1 test_variant_binary_archive_dll: vc-7_1 test_variant_text_archive: vc-7_1 test_variant_text_archive_dll: vc-7_1 test_variant_text_warchive: vc-7_1 test_variant_text_warchive_dll: vc-7_1 test_variant_xml_archive: vc-7_1 test_variant_xml_archive_dll: vc-7_1 test_variant_xml_warchive: vc-7_1 test_variant_xml_warchive_dll: vc-7_1 test_vector_binary_archive: vc-7_1 test_vector_binary_archive_dll: vc-7_1 test_vector_text_archive: vc-7_1 test_vector_text_archive_dll: vc-7_1 test_vector_text_warchive: vc-7_1 test_vector_text_warchive_dll: vc-7_1 test_vector_xml_archive: vc-7_1 test_vector_xml_archive_dll: vc-7_1 test_vector_xml_warchive: vc-7_1 test_vector_xml_warchive_dll: vc-7_1 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

1 0

[Review] Xpressive
by Fred 13 Sep '05

13 Sep '05

* What is your evaluation of the design? * What is your evaluation of the implementation? It's an extremely interesting library, and I really liked many of the design decisions made. I tried converting a simple Spirit grammar into an xpressive regex. I'll admit that this isn't a good idea, at least in my case, but it was an entertaining test of the library. The library seemed to do very well at most things I threw at it. I did run into one or two bugs, but Eric has already fixed them. MSVC7.1 frequently generated internal compiler errors, but the regex I was creating is hopefully significantly more complex than a regex should be. (I didn't profile it, but it looked as though it would be extremely slow as a regex.) One thing that I'd like to see improved is the ability to organize complex regexes. I think one example that I hope is easy to implement would be an ability to name a set of characters. There are a number of literals (_d, _w, etc.) that already do this. I would have found it useful to be able to name my own character sets in static regexes. * What is your evaluation of the documentation? Overall, it was extremely helpful. I did have a few minor complaints that I'll detail below: The syntax cheat sheet should have a string literal added to it. I'd like to see it be complete, and this is the only thing I could find that wasn't there. In addition, I'd like to be able to define character sets of my own that could be used in multiple places in my static regex. I'd like the documentation to better describe the _w identifier. I couldn't find the definition of word character. (I can imagine only one definition making sense, but that's not the same as having a definition.) On the page grammars_and_nested_matches.html, there is a discussion of how the library nicely handles all sorts different lifetime scenarios, but it does not discuss the lifetime of the regex refered to by a regex object that is refered to only through a by_ref clause in another regex. Does by_ref copy the object and manage the lifetime or not? One big advantage of static xpressive regexes is the potential of making a complex regex relatively readable. I'd like to see some discussion of this in the docs. (Something along the lines of http://www.boost.org/libs/spirit/doc/style_guide.html) The documentation of ~as_xpr( character_constant ) should be included. This is a useful construct. * What is your evaluation of the potential usefulness of the library? This will be an extremely useful library. I can see three reasons why this would be valuable to a user: It gives users another set of options to look at when trying to improve the performance of a regex. It makes it possible to create some fairly complex regexes that would be impossible or unreadable with the current boost regex library. The ability to refer to subexpressions in a static regex allows you to make a regex significantly easier to read and understand. Static regexes may be easier to read and understand than traditional string based regex languages, but I don't have enough experience to be confident of that statement. * Did you try to use the library? With what compiler? Did you have any problems? I played with it a bit. (See above.) I used MSVC7.1 and had slight troubles. (I also broke my personal record for long error messages. Even Spirit has never generated a 10MB error message for me before!) * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read the documentation reasonably carefully and spent an afternoon writing some code with it. I did not test the code carefully, but I did get it to compile. * Are you knowledgeable about the problem domain? I've used boost::regex a fair amount. I've also used Spirit occasionally. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes.

2 1

[Concepts] stl_concept_covering test
by Doug Gregor 13 Sep '05

13 Sep '05

This test is failing on a whole lot of compilers. For instance, see: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/ developer/issues.html Actually, a quick review shows that it fails on every compiler out there :) Normally, I'd blame the test itself, but given that this test was meticulously crafted to poke at the corner cases of STL implementations, it's very likely that the test is correct. Would someone volunteer to check out the errors and mark failures in explicit-failures-markup.xml appropriately? Doug

3 2

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

[gmane web interface] why is the latest artivle from the 8th of sep????
by Thorsten Ottosen 12 Sep '05

12 Sep '05

The headline pretty much says it all. Without an up to date web interface, I can't post stuff :-( br -Thorsten

2 1

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

12 Sep '05

<html> <head> <meta http-equiv="refresh" content="1; url=issues-email.txt"> </head> <body> Update in progress (building archive index, done in approximately 6 seconds), please wait... </body> </html>

1 0

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

12 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-03T05:00:17Z 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 Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 85 failures in 11 libraries: foreach (6) graph (4) math (6) mpl (2) multi_index (5) parameter (4) serialization (40) spirit (2) thread (8) typeof (4) wave (4) |foreach| user_defined: cw-8_3 cw-9_4 msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |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 |multi_index| test_capacity: gcc-4_0-darwin test_list_ops: gcc-4_0-darwin test_modifiers: gcc-4_0-darwin test_safe_mode: gcc-4_0-darwin test_update: gcc-4_0-darwin |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |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_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |typeof| type_emulation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

4 4

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

12 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-12T05:00:07Z 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 format concept_check Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 256 failures in 17 libraries: algorithm/string (1) concept_check (11) date_time (44) filesystem (16) foreach (7) format (3) graph (25) iostreams (1) math (6) mpl (2) parameter (4) regex (36) serialization (40) spirit (2) thread (24) typeof (29) 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| testc_local_adjustor: gcc-2.95.3-linux testclock: gcc-2.95.3-linux testdate: gcc-2.95.3-linux testdate_dll: gcc-2.95.3-linux testdate_duration: gcc-2.95.3-linux testdate_duration_dll: gcc-2.95.3-linux testdate_input_facet: gcc-2.95.3-linux testdate_input_facet_dll: gcc-2.95.3-linux testdate_iterator: gcc-2.95.3-linux testdate_iterator_dll: gcc-2.95.3-linux testdst_rules: gcc-2.95.3-linux testdst_transition_day_rule: gcc-2.95.3-linux testduration: gcc-2.95.3-linux testfiletime_functions: gcc-2.95.3-linux testformatters: gcc-2.95.3-linux testformatters_dll: gcc-2.95.3-linux testgenerators: gcc-2.95.3-linux testgenerators_dll: gcc-2.95.3-linux testgreg_cal: gcc-2.95.3-linux testgreg_cal_dll: gcc-2.95.3-linux testgreg_day: gcc-2.95.3-linux testgreg_day_dll: gcc-2.95.3-linux testgreg_duration_operators: gcc-2.95.3-linux testgreg_durations: gcc-2.95.3-linux testgreg_durations_dll: gcc-2.95.3-linux testgreg_month: gcc-2.95.3-linux testgreg_month_dll: gcc-2.95.3-linux testgreg_serialize_xml: vc-7_1 testgreg_year: gcc-2.95.3-linux testgreg_year_dll: gcc-2.95.3-linux testiterator: gcc-2.95.3-linux testlocal_adjustor: gcc-2.95.3-linux 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 testmicrosec_time_clock: gcc-2.95.3-linux testparse_time: gcc-2.95.3-linux testperiod: gcc-2.95.3-linux testperiod_dll: gcc-2.95.3-linux testtime: gcc-2.95.3-linux testtime_formatters: gcc-2.95.3-linux testtime_period: gcc-2.95.3-linux |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 |format| format_test2: vc-7_1 format_test3: vc-7_1 format_test_wstring: vc-7_1 |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 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |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| 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

Problem with Serialization and Building with Managed Extensions
by Jared McIntyre 12 Sep '05

12 Sep '05

I am trying to use boost::serialization in a managed code (CLR) project in Visual Studio. The area that serialization is being used, and all the objects that are being serialized, and standard C++. There are no managed objects related to the serialization process. In fact, I have a test app that reproduces the problem that can be built and run without managed extensions on. But, if I turn building with managed extensions on, several parts of the of the serialization templates turn up missing at link time. I get several errors like the following: LINK : error LNK2020: unresolved token (0A00013F) std._Uninitialized_fill_n<class boost::variant<class TestClass,int,float,double,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boos LINK : error LNK2020: unresolved token (0A000158) std._Uninit_fill_n<class boost::variant<class TestClass,int,float,double,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::detail::variant::void_,struct boost::deta Also, during build, the compiler doesn't like the use of __fastcall in several areas of the code. For example: ..\..\..\..\boost\boost_1_33_0\boost\type_traits\detail\is_mem_fun_pointer_tester.hpp(2443) : warning C4561: '__fastcall' incompatible with the '/clr' option: converting to '__stdcall' I don't know if these are related. I'm using VS 7.1. Does anyone have any thoughts on what I should look at from here? Thanks, Jared McIntyre

1 0

Massive Spamming of the boost Wiki
by Peter Schmitteckert (boost) 12 Sep '05

12 Sep '05

Dear All, sadly, the Boost wiki is currently spammed with a big amount of spam, see e.g. <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?RecentChanges> Since the IP adress is logged, I'd like to ask wether there's a possibility for action. I'm reporting this, because if the spamming continues on this level the wiki will be rendered useless soon. Best regards, Peter

6 7

Re: [boost] read_write_mutex fundamentally broken in 1.33?
by russell＠eminence.com.au 12 Sep '05

12 Sep '05

>>The trouble is what do we do with 1.33.1? We could either revert to the >>1.32 version (if that is actually reliable, the current regression tests >>don't show up these problems so we don't really know), or we could yank >> it >>out of Boost entirely. I'm leaning towards yanking it out at present, >> but >>it's a drastic step, and this presupposes that the original authors of >> the >>class can't temporarily fix things for 1.33.1 (they all look to have >> either >>gone away or be too busy at present however). >> >>What do other folks think? >> >> >> > I don't know either whether someone relies on the presence of rw mutex > being in the > boost. However if he/she is using it, the usage itself is dangerous > anyhow. The company I am working for is actually using timed rw mutex on a current project (and they seem to be working), so I for one would like them to stay in. I suspect timed locks aren't going to deadlock? > In my opinion it is better to omit it until it is fixed. > > I am also not in the mood to dig through the sources to find out how the > design was > intended to work. I would also vote for basing the design on a > theoretically sound > ground (not claiming the current is not) that is understandable too. > > While trying to find out the reason for the initial reported bug I found > myself in a > maze of hard to understand details. Perhaps it would even be better not > to base > the rw mutex on level 0 primitives only, but write it to the native API > of the > respective platform? How should we proceed from here? Should the community come up with a list of alternative implementations that could be evaluated and used as a starting point? Or do we need to go back a step further and decide what types of mutexes or primitives are actually desired?

7 9

Any interest in a chart library
by Schrom, Brian T 12 Sep '05

12 Sep '05

I've been working on a charting library for a few weeks and am wondering whether their would be any interest in having a boost one. I'm not even sure that it makes sense for boost, as it seems a higher level library than most of libraries and also unrelated to other libraries. There would be many things to work out, like no graphics in Boost (that I'm aware of), my not being an expert C++ person, etc, so I'm just trying to get a feel whether it is worth pursuing more here or not, or if there would be another forum that would be better. By charting library, I mean something that you can give data to and that it plots it in a view port, with axis, labels, title etc like you would get with Excel charts, Gnu Plot, Pro-Essentials, etc Thanks, Brian

8 9

File Vault broken
by Eric Niebler 12 Sep '05

12 Sep '05

I just noticed that *everything* in the file vault is gone: http://boost-sandbox.sf.net/vault What's up? -- Eric Niebler Boost Consulting www.boost-consulting.com

6 15

[serialization] XML name lookup table
by Zrubavel Zodikovich 12 Sep '05

12 Sep '05

Robert, There seems to be a minor error that prevents XML tag names from using dot character (and therefore effectively forbidding non-intrusive serialization funtions). The lookup table at basic_xml_oarchive.ipp line 34 should probably look like: 0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,0, // -. Best regards

1 0

[uBLAS] Strange behaviour of LAPACK binding for SVD drivers
by Peter Melchior 12 Sep '05

12 Sep '05

Hello, I'm using LAPACK + bindings to do a Singular Value Decomposition of uBLAS matrices. For inverting a matrix, I need the U and the Vt matrix calculated explicitly. But whatever I give as Jobu and Jobvt, only the Vt matrix will be calculated correctly; the U matrix has only correct diagonal elements. I've tried the Jobu = 'A' setting for gesvd and the Jobz = 'A' setting for gesdd with exactly the same results as JobX = 'O'. I'm using the ublas bindings from CVS (checkout: last Friday, 09.09.2005). Can anybody give me a hint, what might go wrong here. Best regards, Peter

1 0

Boost.Iterator: patch for sunpro CC 5.3
by Graham Bennett 11 Sep '05

11 Sep '05

Hi, Attached is a patch to fix some compilation errors with sunpro CC 5.3. It seems to apply correctly to the current CVS. cheers, Graham. -- Graham Bennett

2 2

TST container (ternary search tree)
by Jose 11 Sep '05

11 Sep '05

Hi, There is a TST implementation in boost/spirit/symbols/impl/tst.ipp and the code mentions "this is a low level class and is not meant for public consumption" I found some old messages in the mailing list describing an effort to package the TST separately of spirit . What is the status of such effort ? thanks Jose

2 1

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

11 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-10T15:19:06Z 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. concept_check Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 149 failures in 10 libraries: concept_check (12) foreach (1) math (3) mpl (1) multi_index (1) numeric/ublas (1) range (6) serialization (110) thread (8) wave (6) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_serialization: intel-win32-9_0 |numeric/ublas| test2: intel-9.0-linux |range| iterator_pair: cw-9_4 gcc-3_3-darwin std_container: cw-9_4 gcc-3_3-darwin string: cw-9_4 gcc-3_3-darwin |serialization| test_cyclic_ptrs_text_warchive_dll: vc-6_5 test_cyclic_ptrs_xml_warchive_dll: vc-6_5 test_delete_pointer_text_warchive_dll: vc-6_5 test_delete_pointer_xml_warchive_dll: vc-6_5 test_demo: intel-win32-8_1 test_demo_dll: borland-5_6_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: borland-5_6_4 test_demo_shared_ptr: intel-win32-8_1 test_demo_shared_ptr_dll: borland-5_6_4 test_demo_xml_dll: borland-5_6_4 test_demo_xml_load: intel-win32-8_1 test_demo_xml_load_dll: borland-5_6_4 test_demo_xml_save: intel-win32-8_1 test_demo_xml_save_dll: borland-5_6_4 test_derived_class_ptr_text_warchive_dll: vc-6_5 test_derived_class_ptr_xml_warchive_dll: vc-6_5 test_derived_text_warchive_dll: vc-6_5 test_derived_xml_warchive_dll: vc-6_5 test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_list_ptrs_text_warchive_dll: vc-6_5 test_list_ptrs_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_non_default_ctor2_text_warchive_dll: vc-6_5 test_non_default_ctor2_xml_warchive_dll: vc-6_5 test_non_default_ctor_text_warchive_dll: vc-6_5 test_non_default_ctor_xml_warchive_dll: vc-6_5 test_non_intrusive_text_warchive_dll: vc-6_5 test_non_intrusive_xml_warchive_dll: vc-6_5 test_null_ptr_text_warchive_dll: vc-6_5 test_null_ptr_xml_warchive_dll: vc-6_5 test_nvp_text_warchive_dll: vc-6_5 test_nvp_xml_warchive_dll: vc-6_5 test_recursion_text_warchive_dll: vc-6_5 test_recursion_xml_warchive_dll: vc-6_5 test_registered_text_warchive_dll: vc-6_5 test_registered_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 intel-win32-8_1 vc-6_5 test_simple_class_ptr_text_warchive_dll: vc-6_5 test_simple_class_ptr_xml_warchive_dll: vc-6_5 test_tracking_text_warchive_dll: vc-6_5 test_tracking_xml_warchive_dll: vc-6_5 test_unregistered_text_warchive_dll: vc-6_5 test_unregistered_xml_warchive_dll: vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: cw-9_4 intel-9.0-linux test_slex_lexer: cw-9_4 intel-9.0-linux testwave: cw-9_4 intel-9.0-linux

1 0

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

11 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-10T15:19:06Z 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. concept_check Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 149 failures in 10 libraries: concept_check (12) foreach (1) math (3) mpl (1) multi_index (1) numeric/ublas (1) range (6) serialization (110) thread (8) wave (6) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_serialization: intel-win32-9_0 |numeric/ublas| test2: intel-9.0-linux |range| iterator_pair: cw-9_4 gcc-3_3-darwin std_container: cw-9_4 gcc-3_3-darwin string: cw-9_4 gcc-3_3-darwin |serialization| test_cyclic_ptrs_text_warchive_dll: vc-6_5 test_cyclic_ptrs_xml_warchive_dll: vc-6_5 test_delete_pointer_text_warchive_dll: vc-6_5 test_delete_pointer_xml_warchive_dll: vc-6_5 test_demo: intel-win32-8_1 test_demo_dll: borland-5_6_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: borland-5_6_4 test_demo_shared_ptr: intel-win32-8_1 test_demo_shared_ptr_dll: borland-5_6_4 test_demo_xml_dll: borland-5_6_4 test_demo_xml_load: intel-win32-8_1 test_demo_xml_load_dll: borland-5_6_4 test_demo_xml_save: intel-win32-8_1 test_demo_xml_save_dll: borland-5_6_4 test_derived_class_ptr_text_warchive_dll: vc-6_5 test_derived_class_ptr_xml_warchive_dll: vc-6_5 test_derived_text_warchive_dll: vc-6_5 test_derived_xml_warchive_dll: vc-6_5 test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_list_ptrs_text_warchive_dll: vc-6_5 test_list_ptrs_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_non_default_ctor2_text_warchive_dll: vc-6_5 test_non_default_ctor2_xml_warchive_dll: vc-6_5 test_non_default_ctor_text_warchive_dll: vc-6_5 test_non_default_ctor_xml_warchive_dll: vc-6_5 test_non_intrusive_text_warchive_dll: vc-6_5 test_non_intrusive_xml_warchive_dll: vc-6_5 test_null_ptr_text_warchive_dll: vc-6_5 test_null_ptr_xml_warchive_dll: vc-6_5 test_nvp_text_warchive_dll: vc-6_5 test_nvp_xml_warchive_dll: vc-6_5 test_recursion_text_warchive_dll: vc-6_5 test_recursion_xml_warchive_dll: vc-6_5 test_registered_text_warchive_dll: vc-6_5 test_registered_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 intel-win32-8_1 vc-6_5 test_simple_class_ptr_text_warchive_dll: vc-6_5 test_simple_class_ptr_xml_warchive_dll: vc-6_5 test_tracking_text_warchive_dll: vc-6_5 test_tracking_xml_warchive_dll: vc-6_5 test_unregistered_text_warchive_dll: vc-6_5 test_unregistered_xml_warchive_dll: vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: cw-9_4 intel-9.0-linux test_slex_lexer: cw-9_4 intel-9.0-linux testwave: cw-9_4 intel-9.0-linux

1 0

Should we kill the YahooGroups files area?
by Doug Gregor 10 Sep '05

10 Sep '05

We have a *much* better solution now, so why not just kill off our YahooGroups ancestry and move on? We could archive what's left in the YahooGroups section by year and make it available in the new vault... Doug

9 11

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

10 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-10T15:19:06Z 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. concept_check Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 149 failures in 10 libraries: concept_check (12) foreach (1) math (3) mpl (1) multi_index (1) numeric/ublas (1) range (6) serialization (110) thread (8) wave (6) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_serialization: intel-win32-9_0 |numeric/ublas| test2: intel-9.0-linux |range| iterator_pair: cw-9_4 gcc-3_3-darwin std_container: cw-9_4 gcc-3_3-darwin string: cw-9_4 gcc-3_3-darwin |serialization| test_cyclic_ptrs_text_warchive_dll: vc-6_5 test_cyclic_ptrs_xml_warchive_dll: vc-6_5 test_delete_pointer_text_warchive_dll: vc-6_5 test_delete_pointer_xml_warchive_dll: vc-6_5 test_demo: intel-win32-8_1 test_demo_dll: borland-5_6_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: borland-5_6_4 test_demo_shared_ptr: intel-win32-8_1 test_demo_shared_ptr_dll: borland-5_6_4 test_demo_xml_dll: borland-5_6_4 test_demo_xml_load: intel-win32-8_1 test_demo_xml_load_dll: borland-5_6_4 test_demo_xml_save: intel-win32-8_1 test_demo_xml_save_dll: borland-5_6_4 test_derived_class_ptr_text_warchive_dll: vc-6_5 test_derived_class_ptr_xml_warchive_dll: vc-6_5 test_derived_text_warchive_dll: vc-6_5 test_derived_xml_warchive_dll: vc-6_5 test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_list_ptrs_text_warchive_dll: vc-6_5 test_list_ptrs_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_non_default_ctor2_text_warchive_dll: vc-6_5 test_non_default_ctor2_xml_warchive_dll: vc-6_5 test_non_default_ctor_text_warchive_dll: vc-6_5 test_non_default_ctor_xml_warchive_dll: vc-6_5 test_non_intrusive_text_warchive_dll: vc-6_5 test_non_intrusive_xml_warchive_dll: vc-6_5 test_null_ptr_text_warchive_dll: vc-6_5 test_null_ptr_xml_warchive_dll: vc-6_5 test_nvp_text_warchive_dll: vc-6_5 test_nvp_xml_warchive_dll: vc-6_5 test_recursion_text_warchive_dll: vc-6_5 test_recursion_xml_warchive_dll: vc-6_5 test_registered_text_warchive_dll: vc-6_5 test_registered_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 intel-win32-8_1 vc-6_5 test_simple_class_ptr_text_warchive_dll: vc-6_5 test_simple_class_ptr_xml_warchive_dll: vc-6_5 test_tracking_text_warchive_dll: vc-6_5 test_tracking_xml_warchive_dll: vc-6_5 test_unregistered_text_warchive_dll: vc-6_5 test_unregistered_xml_warchive_dll: vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: cw-9_4 intel-9.0-linux test_slex_lexer: cw-9_4 intel-9.0-linux testwave: cw-9_4 intel-9.0-linux

1 0

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

10 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-10T05:00:19Z 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… 211 failures in 16 libraries: algorithm/string (1) concept_check (5) date_time (43) filesystem (16) foreach (7) graph (4) iostreams (1) math (6) mpl (2) parameter (4) regex (36) serialization (40) spirit (2) thread (25) typeof (14) wave (5) |algorithm/string| regex: gcc-3_3-darwin |concept_check| stl_concept_covering: gcc-3_4_3-sunos intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 |date_time| testc_local_adjustor: gcc-2.95.3-linux testclock: gcc-2.95.3-linux testdate: gcc-2.95.3-linux testdate_dll: gcc-2.95.3-linux testdate_duration: gcc-2.95.3-linux testdate_duration_dll: gcc-2.95.3-linux testdate_input_facet: gcc-2.95.3-linux testdate_input_facet_dll: gcc-2.95.3-linux testdate_iterator: gcc-2.95.3-linux testdate_iterator_dll: gcc-2.95.3-linux testdst_rules: gcc-2.95.3-linux testdst_transition_day_rule: gcc-2.95.3-linux testduration: gcc-2.95.3-linux testfiletime_functions: gcc-2.95.3-linux testformatters: gcc-2.95.3-linux testformatters_dll: gcc-2.95.3-linux testgenerators: gcc-2.95.3-linux testgenerators_dll: gcc-2.95.3-linux testgreg_cal: gcc-2.95.3-linux testgreg_cal_dll: gcc-2.95.3-linux testgreg_day: gcc-2.95.3-linux testgreg_day_dll: gcc-2.95.3-linux testgreg_duration_operators: gcc-2.95.3-linux testgreg_durations: gcc-2.95.3-linux testgreg_durations_dll: gcc-2.95.3-linux testgreg_month: gcc-2.95.3-linux testgreg_month_dll: gcc-2.95.3-linux testgreg_year: gcc-2.95.3-linux testgreg_year_dll: gcc-2.95.3-linux testiterator: gcc-2.95.3-linux testlocal_adjustor: gcc-2.95.3-linux 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 testmicrosec_time_clock: gcc-2.95.3-linux testparse_time: gcc-2.95.3-linux testperiod: gcc-2.95.3-linux testperiod_dll: gcc-2.95.3-linux testtime: gcc-2.95.3-linux testtime_formatters: gcc-2.95.3-linux testtime_period: gcc-2.95.3-linux |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| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |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 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |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 intel-win32-9_0 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| template_tpl_native: msvc 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

[xpressive] index.html invalid link
by Andy Little 10 Sep '05

10 Sep '05

Hi, link in" libs/xpressive/doc/index.html" is invalid. Enclosed works ok. regards Andy Little

2 1

temp file
by Tomek 10 Sep '05

10 Sep '05

Hi, Can you add to boost::filesystem namespace class for temporary files which will remove file on object destruction ? I prepared same sample code : http://psycho.pl/pub/src/tmpfile.cc If you say that this is ok, I will write it using boost library and also working on win32. Thanks Tom

10 15

[binary-int] pre-release available
by Scott Schurr 10 Sep '05

10 Sep '05

Greetings, At the moment I'm anticipating a formal review of the binary_int implementation sometime in October. This seems like a good time to suggest that anyone who's curious take a look at the pre-release version of binary_int. Anything caught now improves the likelihood that the October review will be the final review. The binary_int template allows the compile time expression of integer binary literals. Usage looks like this: unsigned int regValue = binary_int<1000,1001,0011,0000>::value There is no run-time code overhead for using this template; all overhead is at compile time. I expect these binary literals to work any place that an integer literal would work at compile (not preprocessing) time. The template is designed to allow binary values up to 64-bits to be expressed, although it has only been tested up to 32-bits to date. You'll find the template, its documentation, and a small unit test at: http://boost-consulting.com/vault/ under binary_int.zip In addition to the issue of whether the template works for you, there are four points I'm curious about: o Some compilers used to complain when the most significant bit of a binary_int was set. I've fixed that problem as well as I know how. Do any compilers still see this problem, and does it produce warnings or full fledged errors? o Does the template properly produce 64-bit values on a 64-bit compiler? The unit test only goes up to 32-bits since neither of my compilers support 64-bit compilation. o Are the names 'binary_int' and 'binary_nibble' good names? Pavel Vozenilek, who has very kindly been my Boost mentor, suggests 'bits' and 'nibble' may be better names. o There's a BOOST_WORKAROUND in the template so I can do something vaguely BOOST_STATIC_ASSERT like. Pavel suggests that the workaround would be better solved in a general form that all compilers can accept. What would be a better solution to the BOOST_WORKAROUND? Thanks for your consideration. Scott Schurr

3 10

out of date comment in boost/config/compiler/visualc.hpp
by Marcin Kalicinski 10 Sep '05

10 Sep '05

boost/config/compiler/visualc.hpp has out of date comment at the end: // last known and checked version is 1310: #if (_MSC_VER > 1400) should probably be: // last known and checked version is 1400: #if (_MSC_VER > 1400) cheers, Marcin

2 1

Re: [boost] temp file
by Matt Doyle 09 Sep '05

09 Sep '05

> I didn't know about that, because on win32 there is a problem with > deleting open files. Using the WIN32 call CreateFile specify FILE_ATTRIBUTE_TEMPORARY. from MSDN -> FILE_ATTRIBUTE_TEMPORARY - A file is being used for temporary storage. File systems avoid writing data back to mass storage if sufficient cache memory is available, because an application deletes a temporary file after a handle is closed. In that case, the system can entirely avoid writing the data. Otherwise, the data is written after the handle is closed. You still can't delete an open file but you can possibly avoid ever creating the file in the first place.. Matt > On unix systems (probably most or all of them) > you can delete file and when last handle is closed kernel > automatically > removes file - it's great solution. > > Anyway, same people on unix (in same cases) first open temp file, > then remove it and then use it - no one could do anything > with your file. > > Tom <<snip>> Scanned by Fortigate {X3BTB534}

4 5

read_write_mutex fundamentally broken in 1.33?
by John Maddock 09 Sep '05

09 Sep '05

I've been trying to solve the deadlock problem reported here: http://lists.boost.org/Archives/boost/2005/08/92307.php but I've simply run into more and more problems, and just about every operation I've tried will deadlock if you try hard enough. THIS IS NOT GOOD. Applying Roland Swartz's suggested fix everywhere that looked appropriate initially seemed to fix the issue, but once you move to more complex situations (both readers and writers) then the deadlocks simply come back again. At this point I've exhausted my understanding of the problem and the design of the lock. As an aside: it is *very* hard to implement something like this correctly: no amount of debugging will ever get you a reliable system, only a clearly understood design backed up by a solid theoretical understanding of the implementation method (formal methods anyone?). To be honest I have to question whether it's even a good idea for this to be in Boost (no slur intended towards the implementers of that class, it's the difficulty of the problem that's the issue). In case anyone wants to pursue this further I'm attaching my current test case, and the current patches I have to the implementation, however, please note that neither this test case, nor the current regression tests are anything like comprehensive, THEY WILL NOT CATCH ALL POSSIBLE PROBLEMS. Sorry about the capital letters folks, but I suspect we have a "Huston, we have a problem" moment here :-( Regards, John.

8 15

Re: [boost] temp file
by Matt Doyle 09 Sep '05

09 Sep '05

> Matt Doyle wrote: > >>I didn't know about that, because on win32 there is a problem with > >>deleting open files. > > > > > > Using the WIN32 call CreateFile specify FILE_ATTRIBUTE_TEMPORARY. > > > > from MSDN -> FILE_ATTRIBUTE_TEMPORARY - A file is being > used for temporary storage. File systems avoid writing data > back to mass storage if sufficient cache memory is available, > because an application deletes a temporary file after a > handle is closed. In that case, the system can entirely avoid > writing the data. Otherwise, the data is written after the > handle is closed. > > > > You still can't delete an open file but you can possibly > avoid ever creating the file in the first place.. > > But then you have to carefully craft the spec, as users may > expect to be able to > share the file (by name) among processes. There are clearly > different use > cases for temporary files, so it is important to capture the > most important ones. Ah, that's true. There is a different flag that could be used FILE_FLAG_DELETE_ON_CLOSE which won't delete it until "all" handles to the file are closed but I really can't vouch for it because I haven't used that one. I've no idea what kind of nasty undocumented luggage it brings along with it. Given the source, I like to try it before I believe it ;) Matt > > Regards, > Stefan > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Scanned by Fortigate {X3BTB534}

1 0

Re: [boost] temp file
by Greer, Joe 09 Sep '05

09 Sep '05

While you are thinking about this stuff, keep in mind that some OSes such as win32 have the ability to open a file as temporary and will automatically delete it when the last handle is closed. It would be nice if that could be exploited by whatever interface is decided upon. joe

3 2

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

09 Sep '05

<html> <head> <meta http-equiv="refresh" content="1; url=issues-email.txt"> </head> <body> Update in progress (copying new results), please wait... </body> </html>

2 1

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

09 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-09T15:57:06Z 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. concept_check Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 143 failures in 9 libraries: concept_check (12) foreach (1) math (3) mpl (1) multi_index (1) numeric/ublas (1) serialization (110) thread (8) wave (6) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin |multi_index| test_serialization: intel-win32-9_0 |numeric/ublas| test2: intel-9.0-linux |serialization| test_cyclic_ptrs_text_warchive_dll: vc-6_5 test_cyclic_ptrs_xml_warchive_dll: vc-6_5 test_delete_pointer_text_warchive_dll: vc-6_5 test_delete_pointer_xml_warchive_dll: vc-6_5 test_demo: intel-win32-8_1 test_demo_dll: borland-5_6_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: borland-5_6_4 test_demo_shared_ptr: intel-win32-8_1 test_demo_shared_ptr_dll: borland-5_6_4 test_demo_xml_dll: borland-5_6_4 test_demo_xml_load: intel-win32-8_1 test_demo_xml_load_dll: borland-5_6_4 test_demo_xml_save: intel-win32-8_1 test_demo_xml_save_dll: borland-5_6_4 test_derived_class_ptr_text_warchive_dll: vc-6_5 test_derived_class_ptr_xml_warchive_dll: vc-6_5 test_derived_text_warchive_dll: vc-6_5 test_derived_xml_warchive_dll: vc-6_5 test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_list_ptrs_text_warchive_dll: vc-6_5 test_list_ptrs_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_non_default_ctor2_text_warchive_dll: vc-6_5 test_non_default_ctor2_xml_warchive_dll: vc-6_5 test_non_default_ctor_text_warchive_dll: vc-6_5 test_non_default_ctor_xml_warchive_dll: vc-6_5 test_non_intrusive_text_warchive_dll: vc-6_5 test_non_intrusive_xml_warchive_dll: vc-6_5 test_null_ptr_text_warchive_dll: vc-6_5 test_null_ptr_xml_warchive_dll: vc-6_5 test_nvp_text_warchive_dll: vc-6_5 test_nvp_xml_warchive_dll: vc-6_5 test_recursion_text_warchive_dll: vc-6_5 test_recursion_xml_warchive_dll: vc-6_5 test_registered_text_warchive_dll: vc-6_5 test_registered_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 intel-win32-8_1 vc-6_5 test_simple_class_ptr_text_warchive_dll: vc-6_5 test_simple_class_ptr_xml_warchive_dll: vc-6_5 test_tracking_text_warchive_dll: vc-6_5 test_tracking_xml_warchive_dll: vc-6_5 test_unregistered_text_warchive_dll: vc-6_5 test_unregistered_xml_warchive_dll: vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: cw-9_4 intel-9.0-linux test_slex_lexer: cw-9_4 intel-9.0-linux testwave: cw-9_4 intel-9.0-linux

1 0