- Boost - lists.boost.org

[lexical_cast] performace patch
by Alexander Nasonov 12 Jul '06

12 Jul '06

Hi, I'm preparing a patch to improve a performance of lexical_cast for certain combinations of types. For example, int to char transformation is 5.9 times faster on my FreeBSD. It could be even faster if not a requirement to add a thousands separator. There are few issues I'd like to sort out before I finish the work. 1. Enums, unlike integral types, are not optimized. I don't want to break a conversion from enums with user-defined operator<<. My firm opinion on this is not to support this edge case and allow optimization. 2. To improve a performance even further, I'd like to add lexical_cast< boost::array<N,char> >(arg) but it would break InputStreamable requirement. 3. A couple of conversion functions are good candidates for .cpp file. I expect a strong resistance to this change. Don't get me wrong, I'm not going to change this in default build, I'm asking for new configuration parameter. Something like BOOST_LINK_CORELIB. A user should always link with -lboost_core if BOOST_LINK_CORELIB is defined. That do you think? -- Alexander Nasonov Project Manager at Akmosoft ( http://www.akmosoft.com ) Blog: http://nasonov.blogspot.com Email: $(FirstName) dot $(LastName) at gmail dot com

3 9

Boost regression notification (2006-07-12 [RC_1_34_0])
by Douglas Gregor 12 Jul '06

12 Jul '06

Boost Regression test failures Report time: 2006-07-12T10:04:15Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 412 failures in 31 libraries algorithm/string (1) concept_check (1) conversion (1) filesystem (5) graph (6) integer (3) io (1) iostreams (61) iterator (1) lambda (2) mpl (20) numeric/conversion (4) numeric/interval (2) numeric/ublas (7) optional (2) parameter (33) pool (3) program_options (19) python (92) random (1) rational (5) serialization (43) signals (16) spirit (12) test (8) tr1 (39) type_traits (11) typeof (9) utility (2) utility/enable_if (1) wave (1) |algorithm/string| replace: vc-7_1-stlport |concept_check| class_concept_check_test: vc-7_1-stlport |conversion| lexical_cast_test: sun-5.8 |filesystem| fstream_test: sun-5.8 mbcopy: sun-5.8 operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport wide_test: sun-5.8 |graph| adjacency_matrix_test: vc-7_0 bidir_remove_edge: vc-7_0 csr_graph_test: sun-5.8 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |integer| integer_traits_test: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| array_test: vc-6_5 auto_close_test: sun-5.8 vc-6_5 buffer_size_test: sun-5.8 vc-6_5 bzip2_test: msvc-7.1 msvc-8.0 sun-5.8 code_converter_test: sun-5.8 vc-6_5 component_access_test: sun-5.8 vc-6_5 compose_test: borland-5_6_4 sun-5.8 vc-6_5 copy_test: vc-6_5 counter_test: sun-5.8 vc-6_5 direct_adapter_test: vc-6_5 example_test: vc-6_5 vc-6_5-stlport file_descriptor_test: vc-6_5 file_test: vc-6_5 filtering_stream_test: sun-5.8 vc-6_5 vc-7_1-stlport finite_state_filter_test: cw-9.4 sun-5.8 flush_test: sun-5.8 vc-6_5 gzip_test: msvc-7.1 msvc-8.0 sun-5.8 invert_test: vc-6_5 line_filter_test: sun-5.8 vc-6_5 mapped_file_test: vc-6_5 newline_test: sun-5.8 vc-6_5 null_test: vc-6_5 pipeline_test: sun-5.8 vc-6_5 positioning_test: vc-6_5 regex_filter_test: sun-5.8 vc-6_5 restrict_test: sun-5.8 vc-6_5 seekable_file_test: sun-5.8 vc-6_5 seekable_filter_test: sun-5.8 vc-6_5 stdio_filter_test: sun-5.8 vc-6_5 symmetric_filter_test: sun-5.8 vc-6_5 tee_test: sun-5.8 vc-6_5 wide_stream_test: sun-5.8 vc-6_5 zlib_test: msvc-7.1 msvc-8.0 |iterator| is_lvalue_iterator: sun-5.8 |lambda| extending_rt_traits: sun-5.8 operator_tests_simple: sun-5.8 |mpl| apply: gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc sun-5.8 count: sun-5.8 count_if: sun-5.8 equal: sun-5.8 erase: sun-5.8 find: sun-5.8 insert: sun-5.8 insert_range: sun-5.8 lambda_args: sun-5.8 multiset: gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 partition: sun-5.8 stable_partition: sun-5.8 vector_c: sun-5.8 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| det: sun-5.8 test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |optional| optional_test: sun-5.8 optional_test_ref: sun-5.8 |parameter| basics: borland-5_6_4 borland-5_8_2 sun-5.8 duplicates: borland-5_6_4 borland-5_8_2 earwicker: borland-5_6_4 borland-5_8_2 macros: borland-5_6_4 borland-5_8_2 sun-5.8 maybe: vc-6_5 vc-6_5-stlport vc-7_0 mpl: borland-5_6_4 borland-5_8_2 preprocessor: borland-5_6_4 borland-5_8_2 sun-5.8 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_6_4 borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |pool| test_pool_alloc: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp |program_options| cmdline_test: sun-5.8 cmdline_test_dll: cw-9.4 sun-5.8 options_description_test: sun-5.8 options_description_test_dll: cw-9.4 sun-5.8 parsers_test: sun-5.8 parsers_test_dll: cw-9.4 sun-5.8 positional_options_test: sun-5.8 positional_options_test_dll: cw-9.4 sun-5.8 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test: sun-5.8 variable_map_test_dll: borland-5_8_2 cw-9.4 sun-5.8 winmain_dll: cw-9.4 |python| andreas_beyer: sun-5.8 args: sun-5.8 auto_ptr: sun-5.8 back_reference: sun-5.8 bases: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux sun-5.8 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 borrowed: sun-5.8 callbacks: sun-5.8 const_argument: sun-5.8 crossmod_exception: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 dict: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exception_translator: sun-5.8 exec: cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 extract: sun-5.8 implicit: sun-5.8 indirect_traits_test: sun-5.8 injected: sun-5.8 iterator: sun-5.8 keywords: sun-5.8 list: sun-5.8 long: sun-5.8 minimal: sun-5.8 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: sun-5.8 object: sun-5.8 object_manager: sun-5.8 opaque: sun-5.8 operators: sun-5.8 pearu1: sun-5.8 pickle1: sun-5.8 pickle2: sun-5.8 pickle3: sun-5.8 pickle4: sun-5.8 pointee: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux sun-5.8 pointer_type_id_test: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux sun-5.8 pointer_vector: sun-5.8 polymorphism: sun-5.8 polymorphism2: sun-5.8 polymorphism2_auto_ptr: sun-5.8 properties: sun-5.8 raw_ctor: sun-5.8 return_arg: sun-5.8 select_arg_to_python_test: sun-5.8 select_from_python_test: darwin-4.0.1 qcc-3.3.5_cpp qcc-3.3.5_gpp sun-5.8 select_holder: sun-5.8 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 str: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: sun-5.8 tuple: sun-5.8 upcast: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux sun-5.8 vector_indexing_suite: sun-5.8 virtual_functions: sun-5.8 voidptr: sun-5.8 wrapper_held_type: sun-5.8 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 sun-5.8 vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_binary_text_archive: msvc-8.0 test_codecvt_null: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_demo_fast_archive: sun-5.8 test_demo_fast_archive_dll: sun-5.8 test_demo_portable_archive_dll: vc-6_5 test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_shared_ptr_132_binary_archive: sun-5.8 test_shared_ptr_132_binary_archive_dll: sun-5.8 test_shared_ptr_132_text_archive: sun-5.8 test_shared_ptr_132_text_archive_dll: sun-5.8 test_shared_ptr_132_text_warchive: sun-5.8 test_shared_ptr_132_text_warchive_dll: sun-5.8 test_shared_ptr_132_xml_archive: sun-5.8 test_shared_ptr_132_xml_archive_dll: sun-5.8 test_shared_ptr_132_xml_warchive: sun-5.8 test_shared_ptr_132_xml_warchive_dll: sun-5.8 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_utf8_codecvt: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |signals| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |spirit| bug_fixes: sun-5.8 bug_fixes_debug: sun-5.8 char_strings_test: sun-5.8 char_strings_test_debug: sun-5.8 epsilon_tests: sun-5.8 epsilon_tests_debug: sun-5.8 file_iterator_tests: sun-5.8 file_iterator_tests_debug: sun-5.8 if_p_as_parser_tests: sun-5.8 mix_and_match_trees: sun-5.8 scanner_value_type_tests: intel-linux-9.0 while_p_as_parser_tests: sun-5.8 |test| basic_cstring_test: sun-5.8 boost_check_equal_str: sun-5.8 foreach_test: sun-5.8 ifstream_line_iterator_test: sun-5.8 output_test_stream_test: sun-5.8 parameterized_test_test: vc-6_5 vc-6_5-stlport token_iterator_test: sun-5.8 |tr1| run_random: sun-5.8 std_run_complex_overloads: sun-5.8 std_run_random: sun-5.8 std_test_bind: darwin-4.0.1 sun-5.8 std_test_complex: sun-5.8 std_test_function: sun-5.8 std_test_hash: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 std_test_mem_fn: sun-5.8 std_test_random: sun-5.8 std_test_reference_wrapper: sun-5.8 std_test_result_of: sun-5.8 std_test_shared_ptr: sun-5.8 std_test_tuple: sun-5.8 std_test_tuple_tricky: sun-5.8 std_test_type_traits: sun-5.8 test_bind: darwin-4.0.1 test_boost: vc-7_1-stlport test_hash: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp vc-7_1-stlport test_random: sun-5.8 vc-7_1-stlport test_regex: vc-7_1-stlport test_type_traits: sun-5.8 tr1_extent_test: sun-5.8 tr1_is_abstract_test: sun-5.8 tr1_is_empty_test: sun-5.8 tr1_is_function_test: sun-5.8 tr1_is_member_func_test: sun-5.8 tr1_is_member_obj_test: sun-5.8 tr1_is_object_test: sun-5.8 tr1_is_reference_test: sun-5.8 tr1_rank_test: sun-5.8 tr1_tricky_function_type_test: sun-5.8 |type_traits| decay_test: sun-5.8 extent_test: sun-5.8 is_abstract_test: sun-5.8 is_empty_test: sun-5.8 is_function_test: sun-5.8 is_member_func_test: sun-5.8 is_member_obj_test: sun-5.8 is_object_test: sun-5.8 is_reference_test: sun-5.8 rank_test: sun-5.8 tricky_function_type_test: sun-5.8 |typeof| function_binding_emulation: sun-5.8 function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 nested_typedef_emulation: cw-9.4 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 template_tpl_emulation: sun-5.8 |utility| addressof_test: sun-5.8 operators_test: gcc-3.4.5_linux_x86_64 |utility/enable_if| lazy: sun-5.8 |wave| test_re2c_lexer: sun-5.8

1 0

Is there interest in parallel versions of <algorithm> functions?
by Clint Levijoki 12 Jul '06

12 Jul '06

Hey all, This is actually a 2 part interest inquiry: 1. I think there could be some usefulness in parallel versions of the algorithm functions, like for_each and find and unique_copy. 2. In the couple days of r&d I have come up with a class named parallel_task_master which runs a thread function many times over and manages them so you keep your thread counts low and working as hard as possible. So if you have a quad-core cpu it can be specified so you never go over a 4 thread limit. It's also setup so you can keep adding tasks recursively and it will keep the thread count fixed and never deadlock. Because the tasks in parallel_task_master run relatively in order, I think some sort of queue could be made to parallelize functions that needed to return output in a serial form. So it could be used to decode video stream packets for example. This parallel_task_master in itself may have some value alone, but it was written to assist in creating parallel version of the functions in <algorithm>. Some of them are not so parallelizable, some are embarrassingly so. -Clint Levijoki

5 8

FYI: ASL Boost Patches
by Sean Parent 12 Jul '06

12 Jul '06

ASL (Adobe Source Libraries) provides a set of patches for Boost. There is some general information about the patches here: <http://opensource.adobe.com/wiki/index.php/About_Boost_Patches> Foster just posted details about the specific patches here: <http://opensource.adobe.com/wiki/index.php/ Annotated_List_of_Boost_Patches> We're trying to get better about documenting the patches and making sure boost bugs are filed as appropriate. I thought I'd make this list aware of the changes in case anyone had some feedback. Thanks, Sean

5 6

Re: [boost] Please don't define a fake"operator<"just for ordered containers
by Sean Parent 12 Jul '06

12 Jul '06

More comments - IMHO it is important to come up with a specific set of rules for operator < () than it is to argue about "fake", "feelings", "natural", "expected", and other such terms. What are the semantics of operator <? I'd state the following: 1. It must provide a total ordering (simply a strict weak ordering is not sufficient - for example a strict weak ordering on a pointer could compare just the second byte of the address). 2. Less than ordering must be average constant complexity with worst case complexity proportional to the area of the objects. 3. When there is a strongly established convention for the ordering then that convention should be used. I don't think we have much disagreement on the above points (perhaps some confusion). Now I'd add the following: 4. In the absence of established convention (such as from the domain of mathematics), lexicographical ordering by comparing the parts should be used. Examples from the standard: std::string (which does not sort by established linguistic rules), std::pair, std::vector, std::set, tr1::tuple. Counter examples (which should be fixed): std::complex (real, imaginary). Mathematicians do not have memory or complexity to deal with (mathematicians don't sort) - so arguing that the lack of a rule in mathematics implies that one shouldn't exist in computer science is vacuous. 5. If an object is Incrementable (and/or Decrementable) then the ordering should be such that give: T b(a); ++a; assert (b < a); Examples: pointers within the same array, random access iterators (not forward iterators because of item 2), int This item is potentially debatable (Alex disagrees in his notes - I'll argue it more with him later today). 6. For objects for which a comparison is based upon properties which are not defined across invocations (such as object identity) operator < should not be defined (and not provided where reasonable) Examples: pointers to different arrays, random access iterators to different containers, type_info, forward iterators. For these types, a standard way to get to a total ordering should be provided. Currently we have std::less<> for pointers, type_info::before(), iterators can be converted to pointers - &*iter and then std::less can be used. My recommendation is to use std::less<> - which could be specialized for each of these types. That is std::less<> should provide a total ordering even when operator < does not (but consistent with operator < when it is defined). std::less must still obey 1 and 2. 4a. For composite types for which some of the parts do not define operator < (per item 6). They should define std::less<> based on the lexicographical ordering of the parts using std::less<>. Examples: none - but it would be trivial to specialize std::less<> for pair, tuple, etc. With the above rules, there are _very_ few cases where std::less<> would not be defined (an example would a hash_map where the implementation would violate item 2). If operator < is defined then all comparison operators (>, <=, ==, >=, !=) should be defined consistently. Likewise for std::greater et al. From item 6 - I'd remove the operator < from shared_ptr. If we were going to keep operator < for shared ptr, then I would have to argue to change all of the examples from 6 for consistency (or provide a semantic difference between shared_ptr and these cases. Sean

5 5

boost::plugin
by Philippe Vaucher 12 Jul '06

12 Jul '06

Hello, I did fall on this page http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Plugin… I wondered what was the status of this. Is there any implementation attempt somewhere ? Philippe

5 5

[property map] Document Error?
by Wang Weiwei 12 Jul '06

12 Jul '06

Hello, I'm reading the doc of Boost Property Map, in the part for identity_property_map, it is said, in the 1st table, that the type "boost::property_traits<identity_property_map>::value_type" is void, and that of key_type is also void. But in the file property_map.hpp, I found, struct identity_property_map // ... { typedef std::size_t key_type; typedef std::size_t value_type; // ... } It seems that the key_type and value_type should both be std::size_t. Am I misunderstanding or is it a document error? Thanks. Max

1 0

Re: [boost] Please don't define a fake"operator<"just for ordered containers
by Sean Parent 11 Jul '06

11 Jul '06

> Sean Parent wrote: > > > From item 6 - I'd remove the operator < from shared_ptr. If we were > > going to keep operator < for shared ptr, then I would have to argue > > to change all of the examples from 6 for consistency (or provide a > > semantic difference between shared_ptr and these cases. > > There are two problems with using std::less instead of operator< to > supply a > set/map order. First, it doesn't propagate to composite types; if you > provide a specialization of less<K>, less< pair<K, int> > doesn't > work. Well the same is true for operator < and a simple struct. I'm proposing that the standard be extended to require std::pair<> to supply a less<> specialization. > Second, less<K> is defined as always using K::operator< unless K is > a raw > pointer; it is basically a different name for operator<, one that > can be > used as a predicate. This gives rise to the interpretation that > wherever > less<K> is encountered, the implementation is entitled to use > K::operator< > directly. Not true. 10.3.3.8 gives a fair amount of leeway in the case where operator < does not provide a total ordering (a raw pointer is the only instance given in the standard). We are allowed to specialize classes in the standard with our own types. So boost::tuple could specialize std::less<> without raising any conflicts. > This could have been avoided by defining a separate relation for > set/map > order, either as a function reachable via ADL, or as a function > object, then > making sure that it is defined for all standard value types. Why is this necessary? std::less<> serves us well and avoids the whole ADL mess. > With suitable changes to the standard, less<K> can be made that > relation, > and if this happens, shared_ptr ought to also be changed to reflect > that. There isn't any reason that I can find in the standard not to use less<K> for shared_ptr. It won't work with std::pair<> but I consider that a minor inconvenience. (should we move the discussion to the std reflector?) Sean

3 3

Re: [boost] Please don't define a fake "operator <" just for ordered containers
by Sean Parent 11 Jul '06

11 Jul '06

A quick follow up after discussing this some with Alex, he agrees with my points but also noticed a discrepancy. Item 5 is striving to establish the relationship between the algebraic operators and operator <. We would also like the following to hold: a < b => a + c < b + c A lexicographical compare for std::complex would violate this. So I need to refine item 5 to specify the algebraic relations that should hold and std::complex is no longer a counter example to 4. But std::less<> should be defined for complex under the rules of 4a. Sean

2 1

boost.org main page, what's missing
by Michael Goldshteyn 11 Jul '06

11 Jul '06

The following information should appear on boost.org main page: 1. What is the estimated time frame for the next versioned release of Boost (1.34)? 2. What are the new features/libraries scheduled for 1.34? 3. What are the summarized results of the current nightly build/regression test? Just my $0.02 worth. Mike

1 0