- Boost - lists.boost.org

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

04 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-04T06:00: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. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 294 failures in 13 libraries: bind (7) 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 vc-7_1 |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

Global object initialization [was: Phoenix-2 prerelease]
by David Abrahams 04 Nov '05

04 Nov '05

Joel de Guzman <joel(a)boost-consulting.com> writes: > Comments, feedback very welcome! Here are some sample preset definitions of arg1..argN actor<argument<0> > const arg1 = argument<0>(); actor<argument<1> > const arg2 = argument<1>(); actor<argument<2> > const arg3 = argument<2>(); and its BLL_1.._N style counterparts: You shouldn't use the BLL abbrev., especially not without introducing it first. I suggest "Boost.Lambda" actor<argument<0> > const _1 = argument<0>(); actor<argument<1> > const _2 = argument<1>(); actor<argument<2> > const _3 = argument<2>(); Have you considered the ODR/initialization order implications of this? Eric and I have been discussing this in another context, and it seems to us that you have a choice: 1. The placeholders are statically initialized const POD objects in an unnamed namespace and you have likely ODR violation when used by templates in multiple translation units. 2. The placeholders are dynamically initialized references in an unnamed namespace and you risk undefined behavior when they are used without initialization due to initialization order issues 3. The placeholders are dynamically initialized objects in an unnamed namespace, and you have likely ODR violation *and* initialization order issues Seems from the doc like you have #3, which is the worst of both worlds. No? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] [ANN] Phoenix-2 prerelease
by David Abrahams 04 Nov '05

04 Nov '05

Joel de Guzman <joel(a)boost-consulting.com> writes: > Comments, feedback very welcome! template <typename Eval> struct actor : Eval { return_type operator()() const; template <typename T0> return_type operator()(T0& _0) const; template <typename T0, typename T1> return_type operator()(T0& _0, T1& _1) const; //... }; Is that really what the declaration of actor looks like? I have a hard time believing that there's an identifier called return_type involved. IMO this is just confusing. Are you sure you want to show any code here at all? Oh! and you're using _0, _1, et. al. as parameter names! Wow, really confusing! -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[MPL.Math] semantics of integral_part and fractional_part metafunctions
by Cromwell Enage 04 Nov '05

04 Nov '05

--- Manfred Doubar wrote: > BUT I would expect that both integer and fractional > _parts *included* the sign - and I tend to think > anything else would inevitably lead to confusion. I set up the current semantics of is_negative, integral_part, and fractional_part to match the semantics of the corresponding typedefs in mixed_number_impl. BTW, integral_part used to be called whole_part because it returned whole numbers, which were were nonnegative. > I have a good hint of why you might have gone down > this path, Now you know exactly why. > but I can only think that its going to be cause for > error. No, the difference between our definitions of integral_part and fractional_part will be the cause for error. It turns out that Mathematica <http://mathworld.wolfram.com/> agrees with you, so I'll go ahead and change the metafunction semantics. Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 2

Re: [boost] [ANN] Phoenix-2 prerelease
by David Abrahams 04 Nov '05

04 Nov '05

zvrba(a)globalnet.hr writes: > On Thu, Nov 03, 2005 at 04:55:59PM -0500, David Abrahams wrote: >> >> Rewrite that paragraph: >> > Totally off-topic, but while you're at it.. > > 1. Where did you learn these elements of style? Any online > references? http://www.amazon.com/exec/obidos/tg/detail/-/020530902X/103-0796082-472383… > 2. As for asne.org. Can you please give some navigation on the site > where to find editorial tips (how did you find e.g. > http://www.asne.org/index.cfm?ID=4364 ?) Google. > Is there an index of such tips?o I dunno. > I'm asking because I've found out for myself how hard it is to write a > good, clear and concise text... Strunk & White is the bible. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Website spelling error (still there)
by Jeffrey Williams 04 Nov '05

04 Nov '05

A while back I reported a web site spelling error to this list. It is still there. Which means either I am reporting it to the wrong place, or noone cares or perhaps I am wrong about the spelling error. I'll report it again: On the boost home page, under the latest news in the Serialization library section is says this: Improved seialization of shared pointers Shouldn't this be: Improved serialization of shared pointers Or in the field of serialization does "seialization" actually have a specific meaning? Jeff

1 0

[network] Boost.Network proposal v0.4
by Pedro Lamarão 04 Nov '05

04 Nov '05

Fellow Boosters, this is an update on my proposal for (the beggining of?) a Boost.Network library, located in the "Input - Output" folder of the Sandbox. I consider it feature complete for a 1.0 milestone; the features being: * IOStreams through boost::iostreams (providing a "talker" type model of Device over sockets). * A listener class. * A wrapper for the name resolution services of the system library. * Types to store network addresses with formatted output operators. There's still some more documentation to write, though. Please give one last shot at this proposal. Last time people objected to it as a "Boost.Network" library for not being sufficiently generic (in which it doesn't support "multiplexing" or "asynchronicity"), so perhaps I should move it deeper inside, like, Boost.IOStreams.Network. What do you think? The four components provided could be considered independently: the listener class is as simple as it gets, with a private "accept" method for RAII initialization of whatever socket wrapper type; the model of Device is also as simple as it gets; maybe there is some other interesting stuff to improve the getaddrinfo wrapper and the address types. Possible areas of improvement for the future are: * selector/poller (which is sitting around here waiting) * full formatted input and output for address types * asynchronous resolver (based on Boost.Threads). * Wrapper for sendfile/TransmitFile. -- Pedro Lamarão

2 2

[Boost-bugs] [ boost-Bugs-1348061 ] regex fails to Compile unter Windows and VC++ 7.1
by SourceForge.net 04 Nov '05

04 Nov '05

Bugs item #1348061, was opened at 2005-11-04 01:11 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=1348061&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: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: regex fails to Compile unter Windows and VC++ 7.1 Initial Comment: Hello regex-Developers I have tried to download boost_1_33_0.zip and install boost regex on Windows 2000 using Microsoft Visual Studio .NET 1.1 (C++ compiler version 7.1). Unfortunately, after changing to boost_1_33_0 \libs\regex\build and running nmake -fvc71.mak I get the error that VC++ doesn't know how to make "allocator.hpp" and "regex_library_include.hpp" It appears that allocator.hpp and regex_library_include.hpp are both missing in version 1.33. I copied the files from the 1.32 version, and that solved my problem. Everything compiles fine and seems to work nicely now. Not sure why these files are missing... Could you please include them into the 1.33- version again (they go into boost_1_33_0 \boost\regex\config). Thanks and best regards /Christoph Hänle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1348061&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

Re: [boost] vc8 failures in bind mem_fn_eq
by Victor A. Wagner Jr. 04 Nov '05

04 Nov '05

At 04:14 2005-11-03, Bronek Kozicki wrote: >On 11/3/05, Victor A. Wagner Jr. <vawjr(a)rudbek.com> wrote: > > has the problem been fixed? the results from metacomm show that my > > run at 2005/11/02T2200 has no failures in bind. > >I can definitely see failed test in my today's results. any thoughts on why they're not in my results? the last results of yours I see "posted" are: Wed, 2 Nov 2005 19:01:46 +0000 >B. > >-- >Bronek Kozicki brok(a)spamcop.net http://b.kozicki.pl/ > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Feature Request
by Abajyan, Hambardzum 04 Nov '05

04 Nov '05

Hi (I've already been subscribed my address as you told me to do.) I would like to now why there isn't an implementation of TCP(UDP) Sockets ? I think it's possible to write a good platform-independent architecture based on Berkeley socket interface (supporting asynchronous (non-blocking) sockets), because both Linux and Windows systems support that architecture. There are many libraries like that: e.g. Boost.Thread library which is also platform-independent. In my opinion, this feature is very usefull as with it programmers can develop network applications on Boost. Thanks Best Regards Hambik

1 0