December 2005 - Boost - lists.preview.boost.org

[test]exception safety testing
by Gennadiy Rozental 08 Jan '06

08 Jan '06

Hi, This update includes my first steps in new areas of interaction based testing. One important branch is automated exception safety testing. This scheme was originally used by Dave A. in his work for STLPort testing. And also there was some variation covered in April 2001 CUJ. To employ this new facility one need to include exception_safety.hpp and (most probable) mock_object.hpp. The interface is a single invocation function: namespace itest { void exception_safety( unit_test::callback0<> const& F, unit_test::const_string test_name = "" ); } The function under test should include some statements to be tested for exception safety and checks for invariants using regular Test Tools. Boost.Test will make sure all possible execution patches are tested Faking failures in different locations. Any Test Tool failure is treated as failed invariant and abort specific execution path. Interface also include a helper macro that support auto registration and slightly simplify users life: ------------------------------------------ BOOST_TEST_EXCEPTION_SAFETY( test_name ). ------------------------------------------ Here is an example usage: --------------- // Here is an exempt from simple (incorrect) stack implementation; It is instrumented to better identify failure locations template<class T> class stack { public: explicit stack( int init_capacity = 10 ) : m_capacity( init_capacity ) , m_size( 0 ) , m_v( BOOST_ITEST_NEW(T)[m_capacity] ) { BOOST_ITEST_SCOPE( stack::stack ); } ~stack() { delete[] m_v; } void push( T const& element ) { BOOST_ITEST_SCOPE( stack::push ); if( m_size == m_capacity ) { m_capacity *= 2; T* new_buffer = BOOST_ITEST_NEW( T )[m_capacity]; for( unsigned i = 0; i < m_size; i++ ) { new_buffer[i] = m_v[i]; } delete [] m_v; m_v = new_buffer; } m_v[m_size++] = element; } unsigned size() { return m_size; } private: unsigned m_capacity; unsigned m_size; T* m_v; }; //____________________________________________________________________________// BOOST_TEST_EXCEPTION_SAFETY( test_stack_push ) { stack<mock_object<> > st( 2 ); for( unsigned i = 0; i < 3; ++i ) { try { st.push( simple_mock ); } catch( ... ) { // this invariant checks that in case of failed push number of elements doesn't change BOOST_CHECK_EQUAL( i, st.size() ); throw; } } } This examples shows memory leaks and failed invariants in specific execution paths. Execution path is reported and leaking memory is dumped. New parameter is introduced for Unit Test framework: --break_exec_path=<test_name>:<execution_path_index> Using parameter in conjunction with --catch_system_error=no should allow you to see an execution path causing a memory leak in debugger(Boost.Test will force an abort in failure location). test_name above is the name of the test case and execution_path_index is reported index of execution path containing a memory leak. I would appreciate any comments and subjections for this new facility. Regards, Gennadiy

3 13

Re: [boost] Interest in dimension/unit-checking library?
by Keith Nicewarner 08 Jan '06

08 Jan '06

Geoffrey Romer wrote: > Would there be any interest in a library for attaching units (physical > or otherwise) to numeric variables, so that the type system could > enforce dimension- and unit-consistency in all calculations, and > convert semi-automatically between compatible units? I'm fairly new to boost, so forgive my late entry into this discussion. I too recognized the need for this kind of library back in the late 90s and wrote this library available on SourceForge: http://tuoml.sourceforge.net/ It's pretty stable and used on several projects (there's a military simulation tool that has standardized on it). I've recently discovered the meta-programming method for dimensional quantities by Scott Meyers: http://se.inf.ethz.ch/~meyer/publications/OTHERS/scott_meyers/dimensions.pdf This inspired me to revisit my library and it is turning out to be a fairly easy conversion. The old library had to explicitly represent each unit combination of interest (e.g., Speed = Length/Time), which is ugly and doesn't allow arbitrary combinations. The new method fixes all this (in fact, it simplifies things to the point where there is no library object file any more -- just headers). A key concept I tried to enforce is that any time the programmer sets or gets a numeric value, the specific units (i.e., Feet, Meters, etc.) must be specified. I don't want any units to be implicit. My library provides ostream formatting for handy printing. I also provide scalar, 2D, and 3D types. For the 2D/3D types, I provide various transformation operators like rotation. For 3D rotations, I provide the option of cosine matrix or unit quaternion. It's been suggested to me that I submit my library to boost. Being new to boost, I'm not sure how complete and tested the code needs to be. Any feedback or suggestions are welcome. Keith.

11 37

m4 macro for boost?
by Thomas Porschberg 07 Jan '06

07 Jan '06

Hi, I want integrate some of the boost libraries in a project which has the GNU autoconf/automake tools as build system. I have to cope some questions like: Where is your boost library installed ? Is the version of your boost-lib recent enough ? Can I compile a small program using the boost libraries ? Unfortunately I'm not an experienced GNU auto[conf/make] user. But I note that a lot of software components come with a m4 macro to support the configuration process. I found a boost.m4 file at http://alien.cern.ch/cache/org.glite/project/boost.m4. I tried it to include to my project but it needs some revision. Can someone from the boost people give some advice ? I know that boost does use bjam. But GNU auto[conf/make] are very common(due to cygwin/mingw even under windows) so that I hope to find an answer. best regards, Thomas --

4 9

Boost regression notification (2005-12-01 [HEAD])
by Douglas Gregor 05 Jan '06

05 Jan '06

Boost regression test failures ------------------------------ Report time: 2005-12-01T06:00:10Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 625 failures in 21 libraries: bind (1) concept_check (14) date_time (17) filesystem (5) foreach (5) graph (3) io (1) math (3) mpl (1) multi_array (7) parameter (1) program_options (14) python (289) regex (1) serialization (36) smart_ptr (1) spirit (3) tr1 (171) typeof (24) wave (4) 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 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 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 |filesystem| path_test: mingw-3_4_2 msvc vc-7_1 path_test_dll: msvc vc-7_1 |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| 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 msvc log1p_expm1_test: msvc |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 |program_options| cmdline_test: vc-7_1 cmdline_test_dll: vc-7_1 options_description_test: vc-7_1 options_description_test_dll: vc-7_1 parsers_test: vc-7_1 parsers_test_dll: vc-7_1 positional_options_test: vc-7_1 positional_options_test_dll: vc-7_1 unicode_test: vc-7_1 unicode_test_dll: vc-7_1 variable_map_test: vc-7_1 variable_map_test_dll: vc-7_1 winmain: vc-7_1 winmain_dll: vc-7_1 |python| andreas_beyer: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 args: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 auto_ptr: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 back_reference: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 ben_scott1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 bienstman1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 bienstman2: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 bienstman3: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 builtin_converters: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 callbacks: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 const_argument: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 crossmod_exception: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 data_members: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 defaults: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 dict: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 docstring: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 enum: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 exception_translator: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 exec: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos extract: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 implicit: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 injected: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 iterator: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 keywords: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 list: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 long: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 map_indexing_suite: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 minimal: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 multi_arg_constructor: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 nested: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 numpy: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 object: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 opaque: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 operators: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pearu1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle2: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle3: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle4: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pointer_vector: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 polymorphism: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 polymorphism2: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 polymorphism2_auto_ptr: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 properties: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 raw_ctor: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 return_arg: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 select_from_python_test: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos shared_ptr: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 slice: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 staticmethod: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 stl_iterator: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos msvc vc-7_1 str: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 test_pointer_adoption: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 try: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 tuple: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 vector_indexing_suite: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 virtual_functions: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 wrapper_held_type: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 |regex| grep: 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_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 msvc run_random: msvc std_run_complex_overloads: cw-9_4 gcc-3_4_3-sunos msvc std_run_random: cw-9_4 msvc std_test_array: cw-9_4 msvc std_test_bind: cw-9_4 msvc std_test_boost: msvc std_test_complex: cw-9_4 msvc std_test_function: cw-9_4 msvc std_test_hash: cw-9_4 msvc std_test_mem_fn: cw-9_4 msvc std_test_random: cw-9_4 msvc std_test_reference_wrapper: msvc std_test_regex: cw-9_4 msvc std_test_result_of: cw-9_4 msvc std_test_shared_ptr: msvc std_test_tr1_include: cw-9_4 msvc std_test_tuple: cw-9_4 msvc std_test_type_traits: cw-9_4 msvc test_array: msvc test_bind: cw-9_4 msvc test_complex: cw-9_4 msvc test_function: cw-9_4 msvc test_functional: msvc test_hash: cw-9_4 msvc test_mem_fn: cw-9_4 msvc test_random: cw-9_4 msvc test_reference_wrapper: cw-9_4 msvc test_regex: msvc test_result_of: cw-9_4 msvc test_shared_ptr: cw-9_4 msvc test_tr1_include: cw-9_4 msvc test_tuple: cw-9_4 msvc test_type_traits: msvc test_utility: msvc tr1_add_const_test: cw-9_4 msvc tr1_add_cv_test: cw-9_4 msvc tr1_add_pointer_test: cw-9_4 msvc tr1_add_reference_test: cw-9_4 msvc tr1_add_volatile_test: cw-9_4 msvc tr1_aligned_storage_test: cw-9_4 msvc tr1_alignment_of_test: cw-9_4 msvc tr1_extent_test: cw-9_4 tr1_has_nothrow_assign_test: cw-9_4 msvc tr1_has_nothrow_constr_test: cw-9_4 msvc tr1_has_nothrow_copy_test: cw-9_4 msvc 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 msvc tr1_has_trivial_constr_test: cw-9_4 msvc tr1_has_trivial_copy_test: cw-9_4 msvc tr1_has_trivial_destructor_test: cw-9_4 msvc tr1_has_virtual_destructor_test: cw-9_4 msvc tr1_is_arithmetic_test: cw-9_4 msvc tr1_is_array_test: cw-9_4 msvc tr1_is_base_of_test: cw-9_4 msvc tr1_is_class_test: cw-9_4 msvc tr1_is_compound_test: cw-9_4 msvc tr1_is_const_test: cw-9_4 msvc tr1_is_convertible_test: cw-9_4 msvc tr1_is_empty_test: cw-9_4 msvc tr1_is_enum_test: cw-9_4 msvc tr1_is_floating_point_test: cw-9_4 msvc tr1_is_function_test: cw-9_4 msvc tr1_is_fundamental_test: cw-9_4 msvc tr1_is_integral_test: cw-9_4 msvc tr1_is_member_func_test: cw-9_4 msvc tr1_is_member_obj_test: cw-9_4 msvc tr1_is_member_pointer_test: cw-9_4 msvc tr1_is_object_test: cw-9_4 msvc tr1_is_pod_test: cw-9_4 msvc tr1_is_pointer_test: cw-9_4 msvc tr1_is_polymorphic_test: cw-9_4 msvc tr1_is_reference_test: cw-9_4 msvc tr1_is_same_test: cw-9_4 msvc tr1_is_scalar_test: cw-9_4 msvc tr1_is_signed_test: cw-9_4 msvc tr1_is_union_test: cw-9_4 msvc tr1_is_unsigned_test: cw-9_4 tr1_is_void_test: cw-9_4 msvc tr1_is_volatile_test: cw-9_4 msvc 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 msvc tr1_tricky_add_pointer_test: cw-9_4 msvc tr1_tricky_function_type_test: cw-9_4 msvc tr1_tricky_incomplete_type_test: cw-9_4 msvc tr1_tricky_is_enum_test: cw-9_4 tr1_tricky_partial_spec_test: cw-9_4 msvc |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 vc-7_1 testwave_dll: cw-9_4 vc-7_1 |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

4 15

asio formal review begins
by Jeff Garland 03 Jan '06

03 Jan '06

All - Today (Dec 10th) is the start of the format review of the Asynchronous I/O library (asio) library by Christopher Kohlhoff. The review will run until Friday December 23rd. I will be serving as review manager. From the library synopsis: Boost.Asio is a cross-platform C++ library for network programming that provides developers with a consistent asynchronous I/O model using a modern C++ approach. Downloads of the library as well as online documentation can be found at: http://asio.sourceforge.net/ (please refresh the page if you don't see "Boost Review Material" at the top) http://asio.sourceforge.net/boost-asio-proposal-0.3.6/libs/asio/doc/ As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments Please review early and often! Thanks, Jeff ******************************************************* A Few Library Details: ******************************************************* Supported Platforms The following platforms and compilers have been tested: * Win32 using Visual C++ 7.1 and Visual C++ 8.0. * Win32 using Borland C++Builder 6 patch 4. * Win32 using MinGW. * Linux (2.4 or 2.6 kernels) using g++ 3.3 or later. * Solaris using g++ 3.3 or later. * Mac OS X 10.4 using g++ 3.3 or later. Rationale The Boost.Asio library is intended for programmers using C++ for systems programming, where access to operating system functionality such as networking is often required. In particular, Boost.Asio attempts to address the following goals: * Portability. The library should support, and provide consistent behaviour across, a range of commonly used operating systems. * Scalability. The library should allow, and indeed encourage, the development of network applications that scale to hundreds or thousands of concurrent connections. The library implementation for each operating system should use the mechanism that best enables this scalability. * Efficiency. The library should support techniques such as scatter-gather I/O, and allow protocol implementations that minimise data copying. * Model Berkeley sockets. The Berkeley sockets API is widely implemented and understood, as well as being covered in much literature. Other programming languages often use a similar interface for networking APIs. * Ease of use. Lower the entry barrier for new users by taking a toolkit, rather than framework, approach. That is, try to minimise the up-front investment in time to just learning a few basic rules and guidelines. After that, a library user should only need to understand the specific functions that are being used. * Basis for further abstraction. The library should permit the development of other libraries that provide higher levels of abstraction. For example, implementations of commonly used protocols such as HTTP. Although the current incarnation of Boost.Asio focuses primarily on networking, its concepts of asynchronous I/O can be extended to include other operating system resources such as files.

38 164

[asio] Formal Review
by Giovanni P. Deretta 03 Jan '06

03 Jan '06

Hi everybody, I hope not to have missed the review deadline... First of all I vote *not* to accept asio in boost yet. I think that the library is very promising but there are some issues. If the library is not accepted, is strongly encourage the author to subimit it again once the issues are resolved. - What is your evaluation of the design? Promising. I think that the most important innovation of asio is the dispatcher concept and the async call pattern. Everything else is just *extra*. It probably should be removed in some way from asio and made a separate boost library (or may be just rename asio to something like "asynch lib" or whatever). The interface provided by asio is very low level, but i think this is a strenght of asio, not a weakness. Higher level interfaces (iostreams, buffer management etc...) can be added later as external components or extensions to the library itself. The {datagram|stream}_socket interface is nice, but i have some issues with them. First of all the name "socket" is too much connected with the BSD socket API. I think that asio should go well beyond it and not limit itself to the system socket types (not that it does, but the names might seem to imply that). This is just a personal preference though. Also i think there should be *no* asio::stream_socket. This is my major The current stream socket should be in the namespace asio::ipv4, and should be a different type for example from an eventual asio::posix_pipe::stream_socket or asio::unix::stream_socket. Especially the last can be currently trivially implemented by defining the appropriate protocol. This means that a stream_socket initialized with a ipv4::tcp protocol will interoperate with a stream_socket initialized with a unix::stream protocol. For example, currently i can use my hipotethical unix::stream with ipv4::resolver. Asio should not be type unsafe only because the BSD API is. Of course both should share the same code, but it should be an implementation detail. I like the sync and asynch read/write interface and I have no problem with them being in the same object (i.e. no separation of asynch socket and sync socket). I agree that the proactor patter is the more portable than the reactor one, especially if asio is extended to filesystem i/o. I think the interface could be extended for better efficiency (i will try to describe later how), but this can be done at a later stage. I don't really like a lot the service concept. While I agree that the service repository is useful to hold the various proactor implementations (iocp_service, reactive_service<kqueue>, reactive_service<epoll>, etc...), i don't think that the streams should care about them. As long as the impl_type are interoperable, any stream should be bindable with any service. This also means that the binding with the demuxer should *not* be done at creation time, but at open time. This will make it possible to have different openers: connector, acceptor, unix::socket_pair, posix::pipe etc. The openers are instead created with a demuxer reference and will pass it to the socket when opened. By the way, the implementation of socket functions (accept, connect, read, write, etc) should not be members of the demuxer service but free functions or, better, static members of a policy class. The buffer concept does not really add much, simply using void pointers and size_t length parameters might require less conceptual overhead. They don't add much security (it should be the responsibility of higher layers along with buffer managements), and in practice don't help a lot with scatter/gather i/o: often you can't reuse an existing vector of iovecs, because you need to do an operation from/to the middle of it and thus you need to build a temporary one. As the iovector is usually small (16 elements may be?) and can be stack allocated, I think that having a global buffer type is a premature optimization. Instead there should be a *per stream type*, because a custom stream might use a different iovector implementation that the system one ( io_vec or whatever). It should have at least push_back(void*, size_t) and size() members. Scatter gather operations should accept an iterator to first element of the operation (usually the first element of the vector). The current interface let the user put a socket in non blocking mode, but there is not much that can be done with that, because no reactor is exported. The various reactors/proactor implementations should be removed from the detail namespace and be promoted to public interfaces, albeit in their own namespace (i.e. win32::iocp_proactor, posix::select_reactor, linux::epoll_reactor etc...). This change will make the library a lot more useful. The buffered stream is almost useless. Any operation requires two copies, one from kernel to user space, and one from the internal buffer to the user buffer. The internal buffer should be unlimited in length (using some kind of deque) and accessible to eliminate copies. An interface for i/o that does not require copying would be generally usefull and not limited to buffered streams. - What is your evaluation of the implementation? Good. The code is very clean and readable. Often is more useful than the documentation. There are inefficiencies caused by too much dynamic allocations, mutexes and unnecessary system calls, but they are not intrinsic in the desing and I see from other posting that they are currently being addresed by the author. Probably there should be more code reuse. For example the asio::ssl::stream duplicates much of the code of asio::stream_base. I think that the buffer function does not support vectors with custom allocators, but i might be missing something. On some systems there is already an asynch resolver call (glibc provides getaddrinfo_a). Asio should use them instead of its own thread based emulation. The glibc api still use threads, but a strictly single threaded implementation is theoretically possible. The implemenation is header only. It makes the library easier to use, but network system headers are known to pollute the enviroment :) - What is your evaluation of the documentation? Insufficient. One of the best thing of boost is the quality of its documentation. I don't think that asio is on par with boost standards. While the examples are good and well described, the API documentation is not very useful. It really shows its autogenerated-ness :) - What is your evaluation of the potential usefulness of the library? Extremely useful. There have been lots of requests and proposal for a boost.net library. Asio is certanly the most promising. - Did you try to use the library? While I didn't use all of it (No timers nor SSL), as an experiment I did write a simple continuation library using asio::demuxer as a scheduler and using asio callback pattern to restart coroutines waiting for i/o. Asio's demuxer cleaness and callback guarantees made the implementation very straightforward. If some one is interested i may upload the code somewhere. Currently it is posix only (it uses the makecontext family of system calls), but it should be fairly easy to implement win32 fiber support. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In depth. I've read most of the documentation and studied the implementation, or at leas part of it. - Are you knowledgeable about the problem domain? Yes, a bit. I've written my own network library, although synchronous only. I've studied the asynch problem in depth, but I've only theorethical knowledge of it. I did not add async support to my library because I couldn't find a good async interface. ---- At this point the review if finished. I'will continue with a wish list of the things i would like to see in asio, but don't necessarily belong to a 1.0 version: - Asynchornous completion Tokens. While callbacks are useful most of the time, sometimes ACT are a bettere solution. It would be nice if asio did let the user specify an act instead of a callback to async functions. Then the demuxer would act as a container of ACTs that could be enumerated. - Lazy allocation of buffers. Instead of passing a buffer or a list of buffers to an async io function, a special allocator is passed. When the buffer is needed (before the async syscall on real proactors and before the non blocking call, but after polling on emulated proactors), the allocator is called and it will return a buffer to be used for the operation. The buffer is then passed to the handler. It will eliminate the need to commit buffer memory for inactive connections. This mostly makes sense for reading, but it might be extended to writing too. This optimization make it possible to add... - Multishot calls. Instead of the regular "exactly one callback for async_call", a client might register a callback for multiple wakeups. For example a async_multi_read_some will be called with a buffer allocator and a callback as parameter and will return a registration token. Every time some data is available from the socket, a buffer is allocated, data is read and a callback is done. Note that the same callback is reused, so there is no need to allocate and copy multiple callbacks. This optimization, for example, will greatly reduce the number of syscalls done in reactive demuxer. The notification of interest to the system demuxer is only done once, then as long as the read syscall does not block, no other syscalls need to be done. This will probably be useful mostly with datagram servers. The same optimization can be done to async_accept. - Relinquising ownership of buffers or lending them. While the normal BSD api requires the copying of buffers anyway, there are streams that can be implemented without copying. For example a process-local shared memory stream can be implemented by simply moving pointer to buffers between threads. A buffered stream might take ownership of a supplied buffer and add it to its own buffer list. Giving and taking ownership is not the only action possible, but a immutable buffer could be loaned to a stream. This is useful for caching. For example, when reading from a file a cached file stream can be used. The stream will check in the cache if the file page is present, and if so, it will return a shared, reference counted, pointer to the page as an immutable buffer. As long as the caller only reads from the supplied buffer (for example to send it to a remote host), no copying is required. I think that's all ... for now :). Sorry for the long review. --- Giovanni P. Deretta

5 10

[range] boost::end("hello") is sub-optimal
by Eric Niebler 02 Jan '06

02 Jan '06

There is a bug in Boost.Range that is causing boost::end() to execute a slower code path when called with a string literal. The type of "hello" is char const [6], and end() should be O(1). Indeed, Boost.Range has code to handle just this case, but it never gets called. The problem is the way overload resolution happens between these two functions template< typename T, std::size_t sz > const T* boost_range_end( const T (&array)[sz] ) const char* boost_range_end( const char* s ) The first is O(1) and the second is O(N) becuase it calls strlen. But the second will always be chosen because non-templates are preferred over templates. -- Eric Niebler Boost Consulting www.boost-consulting.com

7 10

[ptr_map] Boost pointer containers, where is the working map type?
by axter 02 Jan '06

02 Jan '06

http://www.boost.org/libs/ptr_container/doc/reference.html I'm trying to use the boost::ptr_map class, and either I'm misunderstanding it's usage or syntax. I originally assumed that a ptr_map class is a map container of pointers and/or container of abstract objects via pointers. However, the example code in the following link, does not seem to be using pointers at all. http://www.boost.org/libs/ptr_container/doc/reference.html Moreover, if I attempt to use an abstract pointer in either the first or second type, I get compile errors. I also tried creating a ptr_map to a base class with a normal virtual function, but when I ran my test, I can see that it slices the derived class. So exactly what is the ptr_map class for, and does anyone have example code that will work with an abstract pointer? I'm trying to compare using the boost pointer containers to using a clone smart pointer. Which boost container would be able to give me functionallity like the following: map<cow_ptr<Shape>, int> mShapeToInt; map<int, cow_ptr<Shape> > mIntToShape; Where Shape is an abstract base class, and cow_ptr is the following: http://code.axter.com/cow_ptr.h

2 1

Re: [boost] ptr_container: ptr_map_adapter interface
by axter 02 Jan '06

02 Jan '06

"Slawomir Lisznianski" <public(a)paramay.com> wrote in message news:<donook$li2$1(a)sea.gmane.org>... > Hello, > > I've been using ptr_map lately and have a few questions regarding its > interface. > > Below is a signature of `insert' function as declared in > ptr_map_adapter: > > std::pair<iterator,bool> insert( key_type& k, value_type x ); > > Why is `k' a non-const reference? > > To imply ownership transfer, couldn't `x' be of > `std::auto_ptr<value_type>' type instead? > > What happend to std::pair as an argument of insert? Was symmetry with > std::map dropped for a reason here? > >From my test, it doesn't seem as though ptr_map has consistent and reliable implementation. I recommend that boost replace the pointer containers with the following smart pointers: http://code.axter.com/copy_ptr.h http://code.axter.com/cow_ptr.h Example usage: std::map<int, cow_ptr<foo> > MyPtrMap; The above type gives you more functionality then the boost::ptr_map type, and of course, it's interface matches the std::map interface. Where as the boost::ptr_map type has the following problems: 1. Doesn't allow you to use an abstract pointer 2. Requires a non-constant argument for the insert function 3. Requires value semantics for the operator[] function 4. When assigning value via operator[] from one container to another, you get object splicing for derived types 5. It doesn't seem to compile on VC++ 6.0, and when it compiles on VC++ 7.1 you get compiler warnings If you use cow_ptr instead, you don't have the above problems. There are similar problems in the boost::ptr_set class, which also can be replaced with cow_ptr or copy_ptr std::set<cow_ptr<foo> > MyPtrSet; IMHO, the entire boost pointer container set of classes can be replace with either cow_ptr and/or copy_ptr, and the result would be a more reliable, and consistent implementation.

2 1

PP re-entrancy question
by Arkadiy Vertleyb 02 Jan '06

02 Jan '06

Hi, The typeof library defines a macro, REGISTER_TEMPLATE, that is intended for use by the library users. Once people started using the library, they eventually wanted to use this macro inside the Boost PP looping constructs, such as SEQ_FOR_EACH, etc. Since the implementation of REGISTER_TEMPLATE itself uses quite a few looping constructs, people ran into re-entrancy issues. I would like the users to be able to use the macro with whichever looping construct they prefer, and, AFAIU, the easiast (only?) way to achieve this would be to limit the macro implementation to only use automatically re-entrant macros, such as BOOST_PP_REPEAT. Is this the right way to go for this particular case, and generally for any macro that is in the library interface? Thanks, Arkadiy

2 5