- Boost - lists.boost.org

Re: [boost] [asio] how detect deadline_timer expired state?
by BRIDGES Dick 30 Sep '05

30 Sep '05

Hi Chris, > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of > Christopher Kohlhoff > Sent: Wednesday, September 28, 2005 6:36 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [asio] how detect deadline_timer expired state? > > > Hi Dick, [snip] > I didn't add an expired() method so as to not make it easy write code > with a race condition ;) (Although strictly speaking you could check > the duration returned by expires_from_now() for the same effect.) I haven't had time go to through the code so I didn't understand the value returned by expires_from_now() when called on timer that expired or had never been set. > The problem with a hypothetical expired() method is that if it returns > true it doesn't actually tell you whether the async_wait's handler has > been delivered yet, i.e. the timer expired but the handler could be > sitting in the demuxer's post queue. Makes perfect sense now that you point it out. State changes are now recorded in the wait handlers - where the state is actually changed. %>] > Another thing is that changing the timer's expiry time while there are > unexpired async_waits has no effect on those waits. In fact I should > change the documentation to make it clear that changing the > expiry time > while there are unexpired waits is "undefined". This design decision > was taken for efficiency reasons, i.e. to avoid having getting or > setting the expiry time need to access a synchronised resource (e.g. > the select_reactor). I agree the documentation should be changed. I experienced some of that "undefined" behavior before I switched to the cancel/set instruction sequence. 8) [snip] > Cheers, > Chris Regards, Dick

1 0

[pool] Why no singleton_object_pool?
by Joel Eidsath 30 Sep '05

30 Sep '05

In [boost.pool], why is there no singleton_object_pool? Or is it already possible to achieve the same behavior? Joel Eidsath

2 4

Re: [boost] What is Boost?
by Scott Schurr 30 Sep '05

30 Sep '05

Someone might take a peek at Scott Meyers "Effective C++, Third Edition". Chapter 55 is entitled, "Familiarize yourself with Boost." I bet there's an excellent summary in there. I'd take a look myself, but my copy is at home. Hope that helps.

1 0

[Review] xpressive
by Thomas Witt 30 Sep '05

30 Sep '05

Hi All, the xpressive review is now officially closed. That being said I know it's not a small library so if anybody(John?) feels like he can provide a review in the next few days I'll be happy to accept it. Thanks Thomas Review Manager xpressive

16 25

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

30 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-30T14:19: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… 73 failures in 4 libraries: foreach (1) iostreams (13) range (3) serialization (56) |foreach| rvalue_const: vc-7_1 |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-3_4_3-sunos gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux mingw-3_4_2 vc-7_1 |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: gcc-3_4_3-sunos 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-30 [HEAD])
by Douglas Gregor 30 Sep '05

30 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-30T05: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… 123 failures in 9 libraries: concept_check (12) graph (2) mpl (1) parameter (12) serialization (33) spirit (8) thread (4) tuple (1) typeof (50) |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 |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 gcc-4_0-darwin 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 unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |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_set_xml_archive: vc-7_1 test_set_xml_warchive: vc-7_1 test_simple_class_ptr_text_warchive_dll: vc-7_1 |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 |typeof| data_member_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_ptr_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 function_ref_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 lvalue_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 member_function_native: cw-9_4 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: cw-9_4 intel-win32-9_0 intel-win32-9_0 std_emulation: cw-9_4 std_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_dependent_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_enum_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_int_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_multiword_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_tpl_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 template_type_native: cw-9_4 intel-win32-9_0 intel-win32-9_0 type_native: cw-9_4 intel-win32-9_0 intel-win32-9_0

1 0

Unit test FP comparisons - memory leaks in debug
by Paul A Bristow 30 Sep '05

30 Sep '05

I have tried to use the Boost 1.33 Unit test FP comparison with MSVC 8.0 beta 2 and the example test_fp_comparisons.cpp works as expected in release mode (runs 5 tests ok) (Though not auto - Had to run it myself). Defines WIN32;NDEBUG;_CONSOLE but in debug mode I get: ------ Rebuild All started: Project: unit_test_framework, Configuration: Debug Win32 ------ Deleting intermediate and output files for project 'unit_test_framework', configuration 'Debug|Win32' Compiling... xml_report_formatter.cpp xml_log_formatter.cpp unit_test_suite.cpp unit_test_parameters.cpp unit_test_monitor.cpp unit_test_main.cpp unit_test_log.cpp test_tools.cpp results_reporter.cpp results_collector.cpp progress_monitor.cpp plain_report_formatter.cpp framework.cpp i:\boost_1_33_0\boost/test/impl/framework.ipp(313) : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned int', possible loss of data execution_monitor.cpp compiler_log_formatter.cpp Generating Code... i:\boost_1_33_0\boost\lexical_cast.hpp(223) : warning C4701: potentially uninitialized local variable 'result' used Creating library... Creating browse information file... Microsoft Browse Information Maintenance Utility Version 8.00.50215 Copyright (C) Microsoft Corporation. All rights reserved. Build log was saved at "file://c:\temp\boost_test_library\Debug\BuildLog.htm" unit_test_framework - 0 error(s), 2 warning(s) ------ Rebuild All started: Project: test_fp_comparisons, Configuration: Debug Win32 ------ Deleting intermediate and output files for project 'test_fp_comparisons', configuration 'Debug|Win32' Compiling... test_fp_comparisons.cpp Linking... Auto run test Running 5 test cases... Detected memory leaks! Dumping objects -> {150} normal block at 0x003163F8, 12 bytes long. Data: <long double > 6C 6F 6E 67 20 64 6F 75 62 6C 65 00 {149} normal block at 0x003163C0, 8 bytes long. Data: < c1 0a1 > F8 63 31 00 30 61 31 00 {139} normal block at 0x00316168, 7 bytes long. Data: <double > 64 6F 75 62 6C 65 00 {138} normal block at 0x00316130, 8 bytes long. Data: <ha1 `41 > 68 61 31 00 60 34 31 00 {126} normal block at 0x00313498, 6 bytes long. Data: <float > 66 6C 6F 61 74 00 {125} normal block at 0x00313460, 8 bytes long. Data: < 41 > 98 34 31 00 00 00 00 00 Object dump complete. Build log was saved at "file://c:\temp\boost_test_library\Debug\BuildLog.htm" test_fp_comparisons - 0 error(s), 0 warning(s) ========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ========== _CONSOLE;WIN32;_DEBUG,BOOST_TEST_NO_AUTO_LINK are defined. Can anyone throw any light on this please? Thanks Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com www.hetp.u-net.com

2 5

Re: [boost] [serialization]A question about the implementation of XML_name in basic_xml_oarchive.ipp
by Martin Bonner 30 Sep '05

30 Sep '05

On 9/28/05, David Abrahams <dave(a)boost-consulting.com> wrote: >>> Hmm... Also, is the apparent dependency on ASCII encoding truly >>> portable? Caleb Epstein wrote: >> Doubtful. Wouldn't testing for std::isalnum || '-' || '_' be a >> better idea? Perhaps not quite as performant (once the lookup table >> was made static), but certainly more portable and simpler to read. Simon Buchan wrote: > In most implementations, the is*()'s are implemented using exactly the > same method. Yes, but the table will be different on an EBCDIC implementation than they are on an ASCII implementation. The point is that the specified table hard codes ASCII, so when somebody runs it on an IBM mainframe it will give the wrong answer. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 2

[serialization]A question about the implementation of XML_name in basic_xml_oarchive.ipp
by Sean Huang 30 Sep '05

30 Sep '05

I ran across the implementation of XML_name. It is a functor used to validate each single character in an XML name. The initialization of a stack-based look-up table everytime the functor is called puzzles me (see excerpt below). void operator()(CharType t) const{ unsigned char lookup_table[] = { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,1,1,0,0,0,0, // -. 1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0, // 0-9 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, // A- 1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,1, // -Z _ 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, // a- 1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0, // -z 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 }; if((unsigned)t > 127) return; if(0 == lookup_table[(unsigned)t]) boost::throw_exception( xml_archive_exception( xml_archive_exception::xml_archive_tag_name_error ) ); } Is there any reason why it was done this way? For threading issues? Thanks, Sean

7 8

Interest in color library.
by Adam Badura 30 Sep '05

30 Sep '05

16 51