- Boost - lists.boost.org

[also 1.33.1] VC8 deprecated library functions and impact on boost
by Stefan Slapeta 02 Nov '05

02 Nov '05

Hi all, As some of you know, there is currently a discussion on the C++ lib reflector about the fact that MS decided to "deprecate" some C/C++ standard library functions on their own behalf. Regardless of whether this may be considered good or not: there is definitely an impact on the boost library because this "feature" causes a LOT of warnings in the boost code. FYI, the log of the stage build printed by the VC 8 final release can be read here: http://tinyurl.com/bhxd8 (just search for "deprecated"). Now, as VC 8 has been released at the MSDN site, there will be more and more users dealing with this compiler who will probably be very much confused about the standard conformity of the boost library. Thus, I suggest to generally set the _SCL_SECURE_NO_DEPRECATE macro (which whould suppress those warnings) for this compiler in boost *even for the 1.33.1 release*!! There may be better solutions for future releases, but I think there must be done something now to avoid a lot of user questions! Thoughts? Stefan P.S.: This warning is printed upon EVERY call of cl.exe: cl : Command line warning D9035 : option 'Og' has been deprecated and will be removed in a future release

14 25

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

02 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-02T14:38:13Z 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… 0 failure in 0 library:

1 0

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

02 Nov '05

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

1 0

[parameter] - catching accidental duplicate parameters at compile time
by Daniel Earwicker 02 Nov '05

02 Nov '05

To take the first code snippet from the tutorial: new_window("alert", width=10, titlebar=false); Suppose the user accidentally does this: new_window("alert", width=10, titlebar=false, width=2); In the current version of the library this compiles, and by examining the source of the library we can discover that one of the values for 'width' will be used and the other discarded (working out which is left as an exercise for the reader.) It would be nice if this was caught at compile time - especially if the parameter "values" are complex expression templates, making it hard to spot the problem at first glance. One implementation would be to add a recursive metafunction to the body of arg_list: template<class SAME_AS> struct find_duplicates { enum { value = (boost::is_same<SAME_AS, key_type>::value || Next::template find_duplicates<SAME_AS>::value) }; }; BOOST_STATIC_ASSERT(!(Next::template find_duplicates<key_type>::value)); And a terminator to empty_arg_list: template<class SAME_AS> struct find_duplicates { enum { value = false }; }; So an arg_list instantiation will not compile if it adds itself to the front of a list that already contains an arg_list entry using the same keyword type. Hope this is worthwhile. --Daniel.

2 1

[filesystem] and 1.33.1 and windows
by Russell Hind 02 Nov '05

02 Nov '05

Given that filesystem can't be used in MSVC and Borland as a dll, why not completely disable filesystem dll builds and force static linking of the lib? This would stop people spending ages finding out why passing filesystem::native fails when you use a dll build. Could be done for 1.33.1? Cheers Russell

1 0

[ublas] equals(matrix<int>, matrix<int>) causes abort
by David Cameron 02 Nov '05

02 Nov '05

I've been writing some code to serialize and deserialize boost::numeric::ublas::matrixs. While writing unit tests for it I found out about the boost::numeric::ublas::equals function in matrix_assign.hpp. I was relieved, because I had previously been using a templated function to compare matrices. Unfortunately, it doesn't work for me with matrix<int>s. Consider the following cppunit test code: void testMatrixEqualsOperator() { using namespace boost::numeric::ublas; matrix<double> test; test.resize(3,3); CPPUNIT_ASSERT( equals(test,test) ); matrix<int> test1; test.resize(4,4); CPPUNIT_ASSERT( equals(test1,test1) ); } The first four lines work. Adding the next three lines causes the unit tests to fail with an Abort. This is not the standard way CppUnit records a failed test, it must be something failing inside the call to equals(). Previous messages referring to the equals() function argued that it wasn't ready for use because there was rarely a need to compare matrices in real applications. I would argue that it should be working as intended, if only to allow for proper unit testing of code that uses matrices. Here is the function I have been using instead. It works well for me with doubles and ints. Although, I imagine it is not particularly fast. E is for Element. template<class E> bool areMatricesEqual( boost::numeric::ublas::matrix<E> lhs, boost::numeric::ublas::matrix<E> rhs) { using boost::numeric::ublas; if (&lhs == &rhs) return true; if (lhs.size1() != rhs.size1()) return false; if (lhs.size2() != rhs.size2()) return false; typename matrix<E>::iterator1 l(lhs.begin1()); typename matrix<E>::iterator1 r(rhs.begin1()); while (l != lhs.end1()) { if (*l != *r) return false; ++l; ++r; } return true; } I am using gcc-3.3 on ubuntu-5.04 running on an AthlonXP. I'd be happy to provide any more info to help track down the bug. Assuming it is one. -- David Cameron University of British Columbia http://bar.psych.ubc.ca/People/Dave.html

1 0

License blanket permissions
by David Abrahams 02 Nov '05

02 Nov '05

Doh! When we were getting permission from library authors to put the Boost License on their works, we forgot to get permission to upgrade the license, if and when there is ever a 2.0 revision (or a 1.1). There's no forseeable need to change the Boost license, but we hope this software will have a longer-than-usual lifespan and unforseen events always come up eventually. So, we're going to begin a project to collect authors' permission to upgrade the license on their work, as necessary. Naturally any new license would conform to the Boost license requirements, and so would be substantially similar in spirit to the one we have now. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 2

Re: [boost] [1.33.1 Beta] Release is imminent
by BRIDGES Dick 02 Nov '05

02 Nov '05

Maybe we should wait until Thursday or Friday if we can. Regards, Dick "Multithreading is just one damn thing after, before, or simultaneous with another." Scott Meyers and Andrei Alexandrescu > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Doug Gregor > Sent: Tuesday, November 01, 2005 10:20 AM > To: boost(a)lists.boost.org > Subject: [boost] [1.33.1 Beta] Release is imminent > > > We now have zero failures on the RC_1_33_0 branch. The > RC_1_33_0 is now > closed for all commits: write to me *directly* if there is something > that absolutely must go into the 1.33.1 release. I will be > rolling the > release tarballs shortly. > > Doug > > On Nov 1, 2005, at 12:00 PM, Douglas Gregor wrote: > > > Boost regression test failures > > ------------------------------ > > Report time: 2005-11-01T14:47: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/issues.html > > > > 0 failure in 0 library: > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Proposal: XML APIs in boost
by Shawn Halpenny 02 Nov '05

02 Nov '05

On 11/1/05, Suman Cherukuri <suman(a)cherukuris.net> wrote: > Xerces has good C++ support. I'm not sure if this discussion is about > extending 'C' based XML parsers like libxml2 and Expat to provide C++ > interface or to have a whole new XML parser within Boost. If it is later, > Why? I agree with Doug Gregor, that something like parsing can be offloaded onto another library like Xerces/libxml2/etc, so I think the value of discussion is in the manipulation and navigation within an XML document. That's where modern C++ techniques could really be applied to great effect. My 2 cents worth regarding the XML libs I've used: Xerces has a bunch of C++ classes ensconced in namespaces, but it feels like a C API dressed up in C++. There is zero in the way of common C++ abstractions for manipulating or accessing a document. It just felt laborious to use--I couldn't escape the thought of "if you're going to write it in C++, how about actually using C++?" With libxml2 I didn't have the "C++ expectations" because it's an all-C API. I still found myself doing the same lower-level node memory-management stuff I had to deal with in Xerces, but I wrote a few brain-dead simple wrapper classes for just the functionality I needed and everything felt so much easier. I suppose the difference is that I expected a whole suite of well-designed wrapper classes along with Xerces and felt let down that they didn't exist. (Plus, I needed RelaxNG schema and XPath support, neither of which Xerces had). -- Shawn Halpenny

1 0

preferred idiom for "occasional properties"
by joel reed 02 Nov '05

02 Nov '05

I've been exploring what a cross platform process library would look like and have a question about whether there is a preferred idiom for what I'll call an occasional property for lack of a better term. Given a process, I'd like to be able to query the parent process. Posix has such a notion, but win32 doesn't. On posix, afaik, every process has a parent except for "init." I can't decide whether I should say class process { public: process parent(); static const process nprocess; // like std::string's npos }; where parent() != nprocess when the process has a parent. or class process { public: typedef std::pair<process,bool> parent_type; parent_type parent(); }; where parent_type.second == true when the process has a parent. I also considered a "parent_iterator", since on posix, you could keep walking backwards up the hierarchy till you get to init, e.g. class parent_iterator; class process { public: parent_iterator parent(); }; but conceptually, I couldn't see a good "end()" Anyone care to offer an idea for the best way to handle this? jr

3 4