- Boost - lists.boost.org

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

13 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-13T05:00:24Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 205 failures in 12 libraries: concept_check (13) graph (2) mpl (1) parameter (13) python (1) serialization (36) spirit (8) thread (4) tuple (1) type_traits (1) typeof (21) xpressive (104) |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 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| exec: intel-win32-9_0 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin 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| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tuple| tuple_test_bench: gcc-3_4_3-sunos |type_traits| tricky_abstract_type_test: intel-win32-9_0 |typeof| data_member_native: cw-9_4 function_native: cw-9_4 msvc function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 msvc member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 msvc template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| misc1: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test1: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 test1u: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 test2: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin intel-win32-9_0 test2u: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin intel-win32-9_0 test3: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 test3u: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin intel-win32-9_0 test4: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test4u: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test5: 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 test5u: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test6: 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 test6u: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test7: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 test7u: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 test8: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 test8u: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 test9: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin intel-win32-9_0 test9u: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin intel-win32-9_0 test_basic_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_cycles: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_dynamic: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_match_results: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_non_char: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_regex_algorithms: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_regex_compiler: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_regex_error: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_regex_iterator: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_regex_primitives: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_regex_token_iterator: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_regex_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_static: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_sub_match: gcc-2.95.3-linux

1 0

What is Boost?
by David Abrahams 13 Oct '05

13 Oct '05

Hi, Last night I hosted a birds-of-a-feather session at the SD Best Practices conferences here in Boston. I was encouraged that, at a conference that only adopted a C++ track this year, we had 15 people there. It was about evenly split between people who were using Boost and those who just came to find out more about it. Those who were using Boost were really enthusiastic. I was stunned to discover that the rest of them reported that wanted to know what Boost _is_, but that the website doesn't tell them. And when they said that, it hit me like a ton of bricks: they're right! We really need a section at the top of the page titled "What is Boost?" that covers something like the following: * Boost is a collection of C++ libraries - Free for any use - Extensively peer-reviewed - Extensively Tested * When you download Boost, you get the whole collection * There are some dependencies among libraries, but they are not tightly coupled * There is a tool (bcp) for extracting the parts you want and their dependencies. * Many boost libraries can be used just by putting the library collection's top directory in your #include path. Complete instructions for getting started are at: ___ * The important features of the Boost directory structure are: - boost - libs - more - tools (with rough descriptions of each) I'd like to see some discussion of what's missing (or extra) in the list above... and a volunteer to write the introductory passage :) -- Dave Abrahams Boost Consulting www.boost-consulting.com

13 42

Re: [boost] Report from Mont Tremblant C++ Committee meeting
by Thorsten Ottosen 13 Oct '05

13 Oct '05

Gennadiy Rozental <gennadiy.rozental <at> thomson.com> writes: > > >>>String-algo : Interested, but concern over interface and choice of > >>>functions, generic vs basic_string.5.3 separate proposal > >> > >> Any details on this? I love this library, and I would love to see it > >> standardized in some form. Overall I've found the interface and function > >> choices to be excellent (and I'd love to see even more), and I love that > >> it's generic and not limited to basic_string. I use it on vectors and > >> other containers for different kinds of network protocol parsing. > > > > Thorsten Ottosen acted as champion for the paper, but I'll try to recall > > the discussion. > > > > There concern was that at least some of the algorithms were only useful in > > the context of strings, and so it would be an over-generalization to > > supply them as free algorithms. My notes say that the solution that got most support was free-standing functions for "arbitrary strings". So support for stuff like rope was considered important. Let me also recap some other feedback: (a) the algorithms should work directly with string literals as they do today in boost. (b) many requested additional motivation for choosing this particular set of functions. > My point exactly. I believe string_algo library went (completely?) wrong > way. It should never use iterator parameterization, but char type only. If > there exist any algorithm that is useful beyond strings - it doesn't belong > to this library. Well, there are just too many string types out there to base the interface on basic_string<CharT>. Besides, it would not be very c++-ish to preach generic programming yet avoid using it in obvious places in the standard library. -Thorsten

1 0

Re: [boost] [ANN] Phoenix-2 prerelease
by Eric Niebler 13 Oct '05

13 Oct '05

Daryle Walker wrote: > On 10/12/05 7:31 PM, "Eric Niebler" <eric(a)boost-consulting.com> wrote: >> iterator begin, end; >> ... >> boost::make_filter_iterator(arg1 > 5, begin, end); >> // Oops! ---------------------------^ >> >>Isn't that comma going to be Phoenix's overloaded comma? > > > I don't think so. The comma used to separate function (call) arguments > always overrides a comma operator. Yeah, you're right, I figured that out with Joel's help yesterday. C++ is funky. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

RTL: Relational Template Library
by Arkadiy Vertleyb 13 Oct '05

13 Oct '05

Hi All. I just uploaded the latest version of Dmitriy Arapov's and my Relational Template Library (RTL) to the Boost file vault, http://tinyurl.com/8lbmg. This version is compatible with Boost 1.33. The RTL was discussed on this list at some time in the past. The early version of RTL is described in the March 2004 issue of CUJ. The main difference from currently discussed RML is that we decided against using SQL - like interface, and use the relational algebra-based interface instead. This choice is caused by our belief that the optimizer -- the module converting SQL query into an optimized relational expression -- is one of the most sophisticated parts of modern database engines. Also, writing a good optimizer in a system like RTL (or RML) would have to be done in large part at compile time, by the means of template meta-programming. This task doesn't seems to be feasible, at least currently. OTOH, writing a primitive optimizer, would, in our opinion do more harm than good. So, the RTL gives its user the possibility to build arbitrary relational expressions by hand. We augment the pure relational algebra with a few things, such as sort order, indexing, groupby, join, etc. We also allow indexing of any relational expressions, not just tables. So, for example, a user can do a selection on some arbitrary complicated criteria, and then index this selection. This would ultimately result in the index storing just keys to these records. This index would be incrementally updated when the underlying table has been changed. Achieving the same effect with conventional approach would require creation of a much larger index on a calculated field. Another example -- you have table of cities, and you need to get all the pairs, such as the distance between them is less than certain number. How would one solve the problem with the conventional SQL approach? This is a self-join. But how to make this query fast? With RTL approach, we could create an index on this self-join. The RTL can currently be compiled with VC7.1 or GCC 3.3+ (although with GCC there might still remain some naming conflicts between MPL and STL, that show up with certain usages) Regards, Arkadiy

6 36

[signals] expected failure markup for como
by Markus Schöpflin 13 Oct '05

13 Oct '05

There are currently two test failures (dead_slot_test, and trackable_test) which are marked as expected for como. The note says: 'The failure is caused by a compiler bug, which has been reported to the compiler supplier (or is already known to them).' Does anyone know the exact circumstances of this compiler bug or even has a small reproducer? Tru64/CXX has the same failures and I would like to submit a bug report to the vendor. Markus

2 3

[signals] usage of any_cast
by Andreas Pokorny 13 Oct '05

13 Oct '05

Hi, We just stumbled across a small problem with Boost.Signals, while playing with the symbol visibility features of gcc-3.4 and gcc-4. That feature is still buggy, but it unveiled some strange code. Somehow gcc failed to turn the type info of the types stored by any into a visible symbol, which is required for using boost::signals across shared libraries. So there are multiple type info objects and the dynamic_casts within signal failed, and the application crashed with a seg fault, since no one expected the cast to fail The code is in signal_template.hpp: template<typename Pair> R operator()(const Pair& slot) const { F* target = const_cast<F*>(any_cast<F>(&slot.second)); return (*target)(BOOST_SIGNALS_BOUND_ARGS); } I dont see why any_cast is used here at all. The type safety is guranteed by the interface of Boost.Signals, so I doubt that someone will be able to abuse the library. I believe the author of that code had the same in mind, since he did not test target != 0 before invoking the target. So in my opinion a simple reinterpret_cast should suffice here. It would also fix our issue, although that one is caused by gcc. Regards Andreas Pokorny

3 5

[mpl] weird interaction between mpl::set and mpl::map headers
by Joaquín Mª López Muñoz 13 Oct '05

13 Oct '05

The following snippet #include <boost/mpl/set/set0.hpp> #include <boost/mpl/map.hpp> int main() { return 0; } produces the following in GCC 3.2: In file included from /usr/local/boost_1_33_0/boost/mpl/map/map0.hpp:18, from /usr/local/boost_1_33_0/boost/mpl/map/map10.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/map20.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map.hpp:36, from mpl_iterator.cpp:2: /usr/local/boost_1_33_0/boost/mpl/map/aux_/contains_impl.hpp:34: no class template named `apply' in `struct boost::mpl::at_impl<boost::mpl::aux::map_tag>' /usr/local/boost_1_33_0/boost/mpl/map/aux_/contains_impl.hpp:35: `type' is not a class or namespace /usr/local/boost_1_33_0/boost/mpl/map/aux_/contains_impl.hpp:35: ISO C++ forbids declaration of `type name' with no type In file included from /usr/local/boost_1_33_0/boost/mpl/map/aux_/erase_key_impl. hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/aux_/erase_impl.hpp: 19, from /usr/local/boost_1_33_0/boost/mpl/map/map0.hpp:22, from /usr/local/boost_1_33_0/boost/mpl/map/map10.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/map20.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map.hpp:36, from mpl_iterator.cpp:2: /usr/local/boost_1_33_0/boost/mpl/map/aux_/has_key_impl.hpp:33: no class template named `apply' in `struct boost::mpl::at_impl<boost::mpl::aux::map_tag>' /usr/local/boost_1_33_0/boost/mpl/map/aux_/has_key_impl.hpp:34: `type' is not a class or namespace /usr/local/boost_1_33_0/boost/mpl/map/aux_/has_key_impl.hpp:34: ISO C++ forbids declaration of `type name' with no type In file included from /usr/local/boost_1_33_0/boost/mpl/map/aux_/begin_end_impl. hpp:20, from /usr/local/boost_1_33_0/boost/mpl/map/map0.hpp:30, from /usr/local/boost_1_33_0/boost/mpl/map/map10.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map/map20.hpp:19, from /usr/local/boost_1_33_0/boost/mpl/map.hpp:36, from mpl_iterator.cpp:2: /usr/local/boost_1_33_0/boost/mpl/map/aux_/iterator.hpp:41: parse error before `<' token /usr/local/boost_1_33_0/boost/mpl/map/aux_/iterator.hpp:62: parse error before `<' token but if I reverse the order of the #includes, everything works OK. I suspect this problem is also showing in the GCC 3.4.x family. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Toolset for VC8.0 and stlport
by Thierry Miceli 13 Oct '05

13 Oct '05

Did somebody make a toolset for VC8.0 and stlport? Thanks, Thierry

2 1

[MPL.Math] partial comeback of big_integral
by Cromwell Enage 13 Oct '05

13 Oct '05

I've rewritten mpl::math::big_integral_impl so that, instead of being a heavyweight mpl::vector, the mantissa (formerly magnitude) is treated as a nullary metafunction containing the integral constant expressions digit_0...digit_N, where N is one less than the mantissa size, which is now directly configurable. Arithmetic operations are now much faster as a result. The functionality that converts integral_c et. al. to a big_integral_impl is now moved to mpl::math::enlarge_integral. All I need now is a *much* more efficient division algorithm and, of course, mpl::math::big_integral itself. BTW, there may be extraneous files in the <mpl_math.zip>boost/ directory; ignore them, I was using them for study purposes. Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 2