- Boost - lists.boost.org

Re: [boost] [wave) experiences
by Martin Bonner 07 Dec '05

07 Dec '05

----Original Message---- From: Paul Mensonides [mailto:pmenso57@comcast.net] Sent: 07 December 2005 09:10 To: boost(a)lists.boost.org Subject: Re: [boost] [wave) experiences > Supporting [extended length integers] is not a good idea. > IMO, it is just the beginning of non-standard extensions. > For the purpose of cross-compiling, I don't have a problem > with an option to specify the width. But what about cross compiling from a 32-bit platform for a 64-bit target? (which strikes me as a perfectly reasonable thing to do today). > IMHO, it is in the community's ultimate best interest for > preprocessors and compilers to be as *un-permissive* as possible. ... but in general I agree with this idea. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

4 5

Re: [boost] BOOST_ENUM proposal
by Job Mulder 07 Dec '05

07 Dec '05

It looks nice, but does it also work with other structures than strings? i.e. BOOST_ENUM(id, (ab_device)("device for your abs", /*activation code*/ 13, /*typical % of time used*/ 0.0) (pc_device)("personal computer", /*activation code*/ 42, /*typical % of time used*/ 100.0) ) -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Frank Laub Sent: Wednesday, December 07, 2005 12:47 To: boost(a)lists.boost.org Subject: [boost] BOOST_ENUM proposal Hello fellow boosters, I've recently come up with a way to use the boost preprocesor to generate a 'better' enum type. The following is an example of some typical usage. Is anyone else interested in this sort of thing? I'm hoping to get suggestions for how to make it more 'boost-like' in both its implementation and its usage. Is this very readable? Is there a place I can upload the code for people to peruse? #include <iostream> #include <boost/enum.hpp> #include <boost/foreach.hpp> #define foreach BOOST_FOREACH BOOST_ENUM(Level, (Abort)("unrecoverable problem") (Error)("recoverable problem") (Alert)("unexpected behavior") (Info)("expected behavior") (Trace)("normal flow of execution") (Debug)("detailed object state listings") ) int main() { foreach(const string& name, Level::names) { cout << name << endl; } cout << "1: " << Level::names[1] << endl; cout << "toString(Abort): " << Level::toString(Level::Abort) << endl; cout << "getValue(Abort): " << Level::getValue(Level::Abort) << endl; Level::type value = Level::Invalid; bool ret = Level::fromString("Abort", value); cout << "fromString(\"Abort\"): " << ret << ", " << value << endl; value = Level::Invalid; ret = Level::fromString("Debug", value); cout << "fromString(\"Debug\"): " << ret << ", " << value << endl; value = Level::Invalid; ret = Level::fromString("not in enum", value); cout << "fromString(\"not in enum\"): " << ret << ", " << value << endl; return 0; } With the program output being: Abort Error Alert Info Trace Debug Invalid 1: Error toString(Abort): Abort getValue(Abort): unrecoverable problem fromString("Abort"): 1, 0 fromString("Debug"): 1, 5 fromString("not in enum"): 0, 6 -Frank _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Boost & Threading
by Jens Hibbeler 07 Dec '05

07 Dec '05

Hello Perhaps anyone can give me a hint, how I get ahead or where my error lies? Which I did: 0) Executed Borland builder Patch No. 4 1) Downloaded Spirit 1.6.3, set environment variable SPIRIT_ROOT on the Spirit listing 2) Set environment variable BCCROOT on c:\programme\borland\cbuilder6 3) Dowloaded the Boost LIBRARY (tried one after the other from 1_32-1_33 beta, all versions), and set the BOOST_ROOT environment variable to the listing in which I boost unpacked. 4) At the Boost tools\build\listing\build.bat executed (compiles correctly for Boland) 5) Executed tools\build\jam_src\bin.ntx86\bjam.exe "- sTOOLS=borland" install (compiled also, but with few warnings) 6) At the listing, in which I unpacked Boost, I started the libs\thread\example file once.cpp 7) I made a Porjekt to compile the file 8) I set atthe project settings the include path on C:\Boost\include\boost-1_32 9) I set atthe project attitudes the LIBRARY path on C:\Boost\lib \ 10) The program compiled and linked 11) When starting the project it crhases immediately and started the monitor, which indicates the storage addresses to me. Where does my error lie? Do I have to adjust something special in the Porjekt still? Many greetings from Hamburg, Jens Hibbeler

1 1

Re: [boost] [smart_ptr] BOOST_SP_USE_QUICK_ALLOCATOR andmulti-threading broken on gcc-4.0.2
by Peter Dimov 07 Dec '05

07 Dec '05

Juergen Hunold wrote: > Hi Again ! > > I've taken another attempt to fix this and found a solution. > > On Wednesday 07 December 2005 20:37, Juergen Hunold wrote: >> Question: Is this a bug or a feature ? > > It's a bug. > >> Question: If this is a bug, whats the fix ? > > Please find the fix attached. Applied, thank you. I have no idea how MSVC 7.1 (that I used to test the modification) was able to eat the original horribly broken code, but it managed to.

1 0

[smart_ptr] BOOST_SP_USE_QUICK_ALLOCATOR and multi-threading broken on gcc-4.0.2
by Juergen Hunold 07 Dec '05

07 Dec '05

Hi ! I'm using smart_ptr (read shared_ptr) and BOOST_SP_USE_QUICK_ALLOCATOR to speed my program up. My programs broke when "boost/detail/quick_allocator.hpp" Revision 1.9 was commited to HEAD. I've been able to reproduce this behaviour with the smart_ptr testcase and Boost.Build V2 which the attached path "smart_ptr.diff" to libs/smart_ptr/test/Jamfile.v2 I'm cross-posting this to boost-build because the simple command bjam --v2 threading=multi/define=BOOST_SP_USE_QUICK_ALLOCATOR did not work. See build-error.txt for full backtrace. The gcc error is ../../../boost/detail/quick_allocator.hpp:176: error: conflicting declaration 'boost::detail::lightweight_mutex boost::detail::allocator_impl<size, align_>::mutex_init' ../../../boost/detail/quick_allocator.hpp:81: error: 'boost::detail::allocator_impl<size, align_>::mutex_init' has a previous declaration as 'boost::detail::lightweight_mutex * boost::detail::allocator_impl<size, align_>::mutex_init' Please find the error message "error.txt" attached. System: Debian Unstable/testing gcc -v : gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) I've tried the obvious fix by adding the missing asterisk (*) gcc complains about but then gcc bails out with ../../../boost/detail/quick_allocator.hpp:176: error: expected primary-expression before 'allocator_impl' (see fix-error.txt) I've checked my copy of "C++ Templates" for static template member (page 97/98) but have no other clue and no copy of the holy standard... Question: Is this a bug or a feature ? Question: Is there any way to add tests for BOOST_SP_USE_QUICK_ALLOCATOR and treading=multi to Boost.Test (V2) in order to catch such a regression. Question: Can someone reproduce this ? Question: If this is a bug, whats the fix ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de

1 0

[math] floating point classification - testing help wanted
by John Maddock 07 Dec '05

07 Dec '05

For a while now I've been meaning to clean up my floating-point classification code to provide a more reliable way of testing for Nan's and infinities. The new TR1 complex number code could really use this to improved it's reliability. I believe Robert Ramey was looking for this functionality for serialisation, and frankly it's hard to write any serious floating point code without it. So... attached is a first version of an fpclassify implementation for Boost (if there's interest). As long as this one works (not a given unfortunately) then it's obviously trivial to sit isnan, isinfinity etc on top of it. So.... I'm looking for testers to run the attached program on as many different platforms/compilers as possible, basically I want to see if there's any mileage in this or if I'm on to a looser with this code! Please build the test program with optimisations turned on: many compilers make non-IEEE arithmetic assumptions once you tell them to optimise the code. Tested so far: Win32: VC6: Can't detect signaling NaN's (_isnan is broken). VC7, 7.1, 8: OK Intel 7, 8, 9: OK provided you're not using the VC6 runtime. GCC cygwin: OK. Borland 5.6.4: So broken I don't know where to begin :-( HP-UX: gcc-3.4.2: OK. aCC: OK (native fpclassify broken for long doubles, but portable version works). Tru64: cxx : OK (but can't test infinities/NaN's as they're not supported? Suse Linux: gcc-3.3.3 : OK. Many thanks, John.

15 44

Re: [boost] [shared_ptr] constructor accepting auto_ptr
by Martin Bonner 07 Dec '05

07 Dec '05

----Original Message---- From: Yuval Ronen [mailto:ronen_yuval@yahoo.com] Sent: 07 December 2005 16:20 To: boost(a)lists.boost.org Subject: Re: [boost] [shared_ptr] constructor accepting auto_ptr > Peter Dimov wrote: >> The reference adds a strong exception safety guarantee. If the >> shared_ptr constructor fails, the source auto_ptr is left intact. >> Pass by value would have already zeroed out the source. >> >> If you want to achieve the equivalent of pass by value, you can use >> an explicit .release(). >> >> This warning would actually be an error on a stricter compiler. >> >> One happy day the compiler writers will bring us the rvalue >> reference, the constructor will take auto_ptr &&, and all will be >> well with the world. :-) > > Does that mean that on a stricter compiler, when passing a temporary > auto_ptr, I *have* to use the '.release()' way, and *can't* get the > strong exception guarantee? No. You can always create a named temporary, and bind the reference to that. > > Thanks a lot to both of you Peter and Howard for your help. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost -- 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

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

07 Dec '05

Boost regression test failures ------------------------------ Report time: 2005-12-06T11:57: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… 6 failures in 2 libraries: graph (5) serialization (1) |graph| layout_test: cw-8_3 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-7_0 |serialization| test_simple_class_ptr_text_warchive_dll: vc-8_0

1 0

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

07 Dec '05

Boost regression test failures ------------------------------ Report time: 2005-12-06T06:00:12Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 294 failures in 18 libraries: bind (1) concept_check (15) date_time (19) foreach (5) graph (5) io (1) math (1) mpl (1) multi_array (7) parameter (1) python (59) serialization (36) smart_ptr (1) spirit (3) tr1 (89) typeof (24) wave (2) xpressive (24) |bind| bind_dm3_test: msvc |concept_check| stl_concept_covering: cw-9_4 cw-9_4 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-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 vc-7_1 |date_time| testc_local_adjustor: msvc testclock: msvc testdst_rules: msvc testfiletime_functions: msvc testgreg_duration_operators: msvc testgreg_serialize_dll: cw-9_4 intel-win32-8_1 intel-win32-9_0 vc-7_1 vc-7_1 testiterator: msvc testlocal_adjustor: msvc testmicrosec_time_clock: msvc testparse_time: msvc testtime: msvc testtime_formatters: msvc testtime_period: msvc testwcustom_time_zone: msvc testwposix_time_zone: msvc |foreach| array_byref: intel-win32-8_1 array_byval: intel-win32-8_1 rvalue_const: intel-win32-9_0 stl_byref: intel-win32-8_1 stl_byval: intel-win32-8_1 |graph| dominator_tree_test: intel-win32-9_0 vc-7_1 graphviz_test: vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |math| complex_test: gcc-3_4_3-sunos |mpl| size_t: gcc-4_0-darwin |multi_array| access: cw-9_4 assign: cw-9_4 assign_to_array: cw-9_4 idxgen1: cw-9_4 index_bases: cw-9_4 iterators: cw-9_4 slice: cw-9_4 |parameter| sfinae: msvc |python| andreas_beyer: gcc-3_4_3-sunos args: gcc-3_4_3-sunos auto_ptr: gcc-3_4_3-sunos back_reference: gcc-3_4_3-sunos ben_scott1: gcc-3_4_3-sunos bienstman1: gcc-3_4_3-sunos bienstman2: gcc-3_4_3-sunos bienstman3: gcc-3_4_3-sunos builtin_converters: gcc-3_4_3-sunos callbacks: gcc-3_4_3-sunos const_argument: gcc-3_4_3-sunos crossmod_exception: gcc-3_4_3-sunos data_members: gcc-3_4_3-sunos defaults: gcc-3_4_3-sunos dict: gcc-3_4_3-sunos docstring: gcc-3_4_3-sunos enum: gcc-3_4_3-sunos exception_translator: gcc-3_4_3-sunos exec: gcc-3_4_3-sunos extract: gcc-3_4_3-sunos implicit: gcc-3_4_3-sunos injected: gcc-3_4_3-sunos iterator: gcc-3_4_3-sunos keywords: gcc-3_4_3-sunos list: gcc-3_4_3-sunos long: gcc-3_4_3-sunos map_indexing_suite: gcc-3_4_3-sunos minimal: gcc-3_4_3-sunos multi_arg_constructor: gcc-3_4_3-sunos nested: gcc-3_4_3-sunos numpy: gcc-3_4_3-sunos object: gcc-3_4_3-sunos opaque: gcc-3_4_3-sunos operators: gcc-3_4_3-sunos pearu1: gcc-3_4_3-sunos pickle1: gcc-3_4_3-sunos pickle2: gcc-3_4_3-sunos pickle3: gcc-3_4_3-sunos pickle4: gcc-3_4_3-sunos pointer_vector: gcc-3_4_3-sunos polymorphism: gcc-3_4_3-sunos polymorphism2: gcc-3_4_3-sunos polymorphism2_auto_ptr: gcc-3_4_3-sunos properties: gcc-3_4_3-sunos raw_ctor: gcc-3_4_3-sunos return_arg: gcc-3_4_3-sunos select_from_python_test: gcc-3_4_3-sunos shared_ptr: gcc-3_4_3-sunos slice: gcc-3_4_3-sunos staticmethod: gcc-3_4_3-sunos stl_iterator: gcc-3_4_3-sunos msvc str: gcc-3_4_3-sunos test_pointer_adoption: gcc-3_4_3-sunos try: gcc-3_4_3-sunos tuple: gcc-3_4_3-sunos vector_indexing_suite: gcc-3_4_3-sunos virtual_functions: gcc-3_4_3-sunos wrapper_held_type: gcc-3_4_3-sunos |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 |smart_ptr| shared_ptr_alloc2_test: msvc |spirit| multi_pass_compile_tests: intel-win32-8_1 traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |tr1| run_complex_overloads: cw-9_4 gcc-3_4_3-sunos std_run_complex_overloads: cw-9_4 gcc-3_4_3-sunos std_run_random: cw-9_4 std_test_array: cw-9_4 std_test_bind: cw-9_4 std_test_complex: cw-9_4 std_test_function: cw-9_4 std_test_hash: cw-9_4 std_test_mem_fn: cw-9_4 std_test_random: cw-9_4 std_test_regex: cw-9_4 std_test_result_of: cw-9_4 std_test_tr1_include: cw-9_4 std_test_tuple: cw-9_4 std_test_type_traits: cw-9_4 test_bind: cw-9_4 test_complex: cw-9_4 test_function: cw-9_4 test_hash: cw-9_4 test_mem_fn: cw-9_4 test_random: cw-9_4 test_reference_wrapper: cw-9_4 test_result_of: cw-9_4 test_shared_ptr: cw-9_4 test_tr1_include: cw-9_4 test_tuple: cw-9_4 tr1_add_const_test: cw-9_4 tr1_add_cv_test: cw-9_4 tr1_add_pointer_test: cw-9_4 tr1_add_reference_test: cw-9_4 tr1_add_volatile_test: cw-9_4 tr1_aligned_storage_test: cw-9_4 tr1_alignment_of_test: cw-9_4 tr1_extent_test: cw-9_4 tr1_has_nothrow_assign_test: cw-9_4 tr1_has_nothrow_constr_test: cw-9_4 tr1_has_nothrow_copy_test: cw-9_4 tr1_has_tr1_ref_wrap_fail: cw-9_4 tr1_has_tr1_shared_ptr_fail: cw-9_4 tr1_has_tr1_tuple_fail: cw-9_4 tr1_has_trivial_assign_test: cw-9_4 tr1_has_trivial_constr_test: cw-9_4 tr1_has_trivial_copy_test: cw-9_4 tr1_has_trivial_destructor_test: cw-9_4 tr1_has_virtual_destructor_test: cw-9_4 tr1_is_arithmetic_test: cw-9_4 tr1_is_array_test: cw-9_4 tr1_is_base_of_test: cw-9_4 tr1_is_class_test: cw-9_4 tr1_is_compound_test: cw-9_4 tr1_is_const_test: cw-9_4 tr1_is_convertible_test: cw-9_4 tr1_is_empty_test: cw-9_4 tr1_is_enum_test: cw-9_4 tr1_is_floating_point_test: cw-9_4 tr1_is_function_test: cw-9_4 tr1_is_fundamental_test: cw-9_4 tr1_is_integral_test: cw-9_4 tr1_is_member_func_test: cw-9_4 tr1_is_member_obj_test: cw-9_4 tr1_is_member_pointer_test: cw-9_4 tr1_is_object_test: cw-9_4 tr1_is_pod_test: cw-9_4 tr1_is_pointer_test: cw-9_4 tr1_is_polymorphic_test: cw-9_4 tr1_is_reference_test: cw-9_4 tr1_is_same_test: cw-9_4 tr1_is_scalar_test: cw-9_4 tr1_is_signed_test: cw-9_4 tr1_is_union_test: cw-9_4 tr1_is_unsigned_test: cw-9_4 tr1_is_void_test: cw-9_4 tr1_is_volatile_test: cw-9_4 tr1_rank_test: cw-9_4 tr1_remove_all_extents_test: cw-9_4 tr1_remove_const_test: cw-9_4 tr1_remove_cv_test: cw-9_4 tr1_remove_extent_test: cw-9_4 tr1_remove_pointer_test: cw-9_4 tr1_remove_reference_test: cw-9_4 tr1_remove_volatile_test: cw-9_4 tr1_tricky_abstract_type_test: cw-9_4 tr1_tricky_add_pointer_test: cw-9_4 tr1_tricky_function_type_test: cw-9_4 tr1_tricky_incomplete_type_test: cw-9_4 tr1_tricky_is_enum_test: cw-9_4 tr1_tricky_partial_spec_test: cw-9_4 |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 cw-9_4 modifiers_native: cw-9_4 cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 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 |wave| testwave: cw-9_4 testwave_dll: cw-9_4 |xpressive| misc1: cw-9_4 test1: cw-9_4 test1u: cw-9_4 test2: cw-9_4 test2u: cw-9_4 test3: cw-9_4 test3u: cw-9_4 test4: cw-9_4 test4u: cw-9_4 test5: cw-9_4 test5u: cw-9_4 test6: cw-9_4 test6u: cw-9_4 test7: cw-9_4 test7u: cw-9_4 test8: cw-9_4 test8u: cw-9_4 test9: cw-9_4 test9u: cw-9_4 test_cycles: cw-9_4 test_dynamic: cw-9_4 test_non_char: cw-9_4 test_regex_primitives: cw-9_4 test_static: cw-9_4

1 0

[shared_ptr] constructor accepting auto_ptr
by Yuval Ronen 07 Dec '05

07 Dec '05

Hi. There's a shared_ptr constructor that accepts an auto_ptr<Y>&. Shouldn't it accept auto_ptr<Y> by value rather by non-const reference? It seems to me that the reference does not add anything, but only causes a VC warning (level 4): --- warning C4239: nonstandard extension used : 'argument' : conversion from 'std::auto_ptr<_Ty>' to 'std::auto_ptr<_Ty> &' A reference that is not to 'const' cannot be bound to a non-lvalue --- when calling this constructor with a temporary auto_ptr. This warning is a good thing and I don't want to disable it. Thanks, Yuval

5 7