October 2005 - Boost - lists.boost.org

[asio] init acceptor to reuse_address?
by BRIDGES Dick 04 Oct '05

04 Oct '05

I submitted this question to boost-users Friday but it occurred to me that it should have been posted here. Apologies if I've erred. <original> I created a server something like this: handle_accept(){ do_the_right_thing(); } Class Foo { socket_acceptor acceptor_; Public: Foo(demuxer& d) : acceptor_( d, ipv4::tcp::endpoint(2525)){} Example(demuxer& d) { stream_socket* p = new stream_socket(d); acceptor_.async_accept(p, handle_accept); } } Everything works fine except when I (1) connect a client; (2) ^C the server; (3) try to restart the server - which, as expected, yields "Address already in use". Mumbling something about defaulting modern socket libraries to SO_REUSEADDR, I started trying to figure out where to call set_option(stream_socket::reuse_address(true)) - and can't work it out. I've set_option() on sockets and the acceptor but can't make the acceptor reuse the address as long as the connection that was established is still in TIME_WAIT. Do you have an example that shows how this can be done? </original> Regards, Dick Bridges

2 3

[Solved]:Serialization
by Stefan 04 Oct '05

04 Oct '05

Sorry guys, forget my earlier posting. I just looked at the c++ reference and saw, that there is a ostringstream, which is what I needed, I haven't done to much c++ yet, didn't know there was such a stream class :-( Cheers Stefan ___________________________________________________________ Was denken Sie über E-Mail? Wir hören auf Ihre Meinung: http://surveylink.yahoo.com/wix/p0379378.aspx

1 0

[scope_guard] New revision available + naming consideration
by Andrey Semashev 03 Oct '05

03 Oct '05

The new version is available in the Sandbox (I moved it into Function objects): http://boost-consulting.com/vault/index.php?action=downloadfile&filename=sc… Here is a shord summary about changes: - Various cosmetic changes, including macro and function names. - Exception support code (with_catcher policy) moved into a separate file. - Added a helper function "catching" to simplify use of with_catcher policy. - Unique names generating code moved into a separate file. By the way, maybe this code should better be in Boost.Preprocessor? See boost/guard/unique_names.hpp. - Revised the guard_ptr class, moved it up to boost namespace. It is now resided in guard_ptr.hpp. - The actions_trace class was considered to be too specific and was eliminated. The new guard_adapter class is supposed to expand the functionality of holding scope guards in containers to every STL-compatible container (sequental or associative) and even to the standard container wrappers such as stack, queue or priority_queue. See guard_adapter.hpp for more details. - I hope I've fixed problems with VC6 (and even maybe BCB) I've been reported, but I can't tell for sure since I can't try it. At least the code that uses scope_guard.hpp should work (once again, I hope). Maybe I'll have a chance to test it on VC6 in a week or two, but now I'm walking blindly. As always, I've tried it on VC7.1, ICL9 and MinGW (GCC 3.4.4). Few words about what I'm concerned about: - The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this. - The naming of the function make_guarded_call (in previous version it was make_transaction) is what I'm not sure of. This function in addition to a scope_guard creation calls some another functor. The semantic is grouping the "do" and "undo" actions in the user code. Does anyone have a better name? - I have received a proposal of ability to allocate space for several scope_guards on the stack. In current implementation when using guard_adapter and guard_ptr with some container the guard objects will be allocated in the heap which might be slightly slower than if it would be on the stack. So the most probable implementation of such proposal shall be a separate static container. Does anyone have any thoughts about this? How much would you need such functionality? I think, I've reached some point release (unless anyone have proposal about namings). At least, the main scope guard implementation seems to be stable. So I would like to check in this version to CVS (or, maybe, if someone do this for me) if there are no arguments against this. Once I have done this I could start making BoostBook docs (now there are only doxygen-like comments in the code) and make some unit tests.

13 37

[Boost-bugs] [ boost-Bugs-1312222 ] many "virtual functions vs. non-virtual destructor" warnings
by SourceForge.net 03 Oct '05

03 Oct '05

Bugs item #1312222, was opened at 2005-10-03 12:20 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=1312222&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: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Robert Ramey (ramey) Summary: many "virtual functions vs. non-virtual destructor" warnings Initial Comment: Hello, seems since RC1_1_33_0 the amount of warning has increased once more. Compling with gcc 4.02 with "-Wall -pedantic" It's pretty annyoing and floods the output unnecessary. Other parts of boost dont have this problem... ---- snip --- boost/boost/archive/binary_iarchive.hpp:33: warning: 'class boost::archive::binary_iarchive_i mpl<boost::archive::binary_iarchive>' has virtual functions but non-virtual destructor /home/rmichels/minimon/sdk/boost/boost/archive/binary_iarchive.hpp:76: warning: 'class boost::archive::binary_iarchive' has virtual functions but non-virtual destructor boost/boost/archive/detail/common_oarchive.hpp:31: warning: 'class boost::archive::detail::co mmon_oarchive<boost::archive::binary_oarchive>' has virtual functions but non-virtual destructor boost/boost/archive/basic_binary_oarchive.hpp:53: warning: 'class boost::archive::basic_binar y_oarchive<boost::archive::binary_oarchive>' has virtual functions but non-virtual destructor boost/boost/archive/basic_xml_iarchive.hpp:40: warning: 'class boost::archive::basic_xml_iarc hive<boost::archive::xml_iarchive>' has virtual functions but non-virtual destructor boost/boost/archive/xml_iarchive.hpp:39: warning: 'class boost::archive::xml_iarchive_impl<bo ost::archive::xml_iarchive>' has virtual functions but non-virtual destructor -------------------- There are some more ... Whats the purpose of not having virtual dtor but virtual functions? Could you please supply a solution, this stuff clutters output much. Regards, A. Focht ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1312222&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost regression notification (2005-10-03 [RC_1_33_0])
by Douglas Gregor 03 Oct '05

03 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-03T15:12:19Z 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… 221 failures in 6 libraries: foreach (1) iostreams (13) multi_index (1) range (3) serialization (202) wave (1) |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 |multi_index| test_serialization: cw-9_5-darwin |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_binary_text_archive: vc-7_1 test_binary_text_archive_dll: vc-7_1 test_class_info_save_text_archive: vc-7_1 test_class_info_save_text_archive_dll: vc-7_1 test_delete_pointer_binary_archive: cw-9_5-darwin test_delete_pointer_binary_archive_dll: cw-9_5-darwin test_delete_pointer_text_archive: cw-9_5-darwin test_delete_pointer_text_warchive: cw-9_5-darwin test_delete_pointer_xml_archive: cw-9_5-darwin test_delete_pointer_xml_warchive: cw-9_5-darwin test_demo_polymorphic: cw-9_5-darwin test_demo_xml_load: gcc-3_3-darwin gcc-4_0-darwin intel-win32-8_1 test_demo_xml_load_dll: gcc-3_3-darwin gcc-4_0-darwin test_deque_binary_archive: cw-9_5-darwin test_deque_binary_archive_dll: cw-9_5-darwin test_deque_text_archive: cw-9_5-darwin test_deque_text_warchive: cw-9_5-darwin test_deque_xml_archive: cw-9_5-darwin test_deque_xml_warchive: cw-9_5-darwin test_derived_text_archive: vc-7_1 test_derived_text_archive_dll: vc-7_1 test_exported_binary_archive: gcc-3.2.3-linux gcc-4.0.1-linux intel-9.0-linux vc-6_5 test_exported_binary_archive_dll: gcc-4.0.1-linux vc-6_5 test_exported_text_archive: gcc-3.2.3-linux gcc-4.0.1-linux vc-6_5 vc-7_1 test_exported_text_archive_dll: gcc-3.2.3-linux gcc-4.0.1-linux vc-6_5 vc-7_1 test_exported_text_warchive: gcc-4.0.1-linux vc-6_5 test_exported_text_warchive_dll: gcc-4.0.1-linux vc-6_5 test_exported_xml_archive: gcc-4.0.1-linux intel-8.1-linux vc-6_5 test_exported_xml_archive_dll: gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux vc-6_5 test_exported_xml_warchive: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux vc-6_5 test_exported_xml_warchive_dll: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux vc-6_5 test_list_binary_archive: cw-9_5-darwin test_list_binary_archive_dll: cw-9_5-darwin test_list_ptrs_binary_archive: cw-9_5-darwin test_list_ptrs_binary_archive_dll: cw-9_5-darwin test_list_ptrs_text_archive: cw-9_5-darwin test_list_ptrs_text_warchive: cw-9_5-darwin test_list_ptrs_xml_archive: cw-9_5-darwin test_list_ptrs_xml_warchive: cw-9_5-darwin test_list_ptrs_xml_warchive_dll: gcc-3_4_3-sunos test_list_text_archive: cw-9_5-darwin test_list_text_warchive: cw-9_5-darwin test_list_xml_archive: cw-9_5-darwin test_list_xml_warchive: cw-9_5-darwin test_map_binary_archive: cw-9_5-darwin test_map_binary_archive_dll: cw-9_5-darwin test_map_text_archive: cw-9_5-darwin gcc-3_4_3-sunos test_map_text_warchive: cw-9_5-darwin test_map_xml_archive: cw-9_5-darwin test_map_xml_warchive: cw-9_5-darwin test_mi_text_archive: vc-7_1 test_mi_text_archive_dll: vc-7_1 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_non_default_ctor2_text_archive: vc-7_1 test_non_default_ctor2_text_archive_dll: vc-7_1 test_non_default_ctor_text_archive: vc-7_1 test_non_default_ctor_text_archive_dll: vc-7_1 test_non_intrusive_text_archive: vc-7_1 test_non_intrusive_text_archive_dll: vc-7_1 test_null_ptr_text_archive: vc-7_1 test_null_ptr_text_archive_dll: vc-7_1 test_object_text_archive: vc-7_1 test_object_text_archive_dll: vc-7_1 test_polymorphic_binary_archive: cw-9_5-darwin test_polymorphic_binary_archive_dll: cw-9_5-darwin test_polymorphic_text_archive: cw-9_5-darwin test_polymorphic_text_warchive: cw-9_5-darwin test_polymorphic_xml_archive: cw-9_5-darwin test_polymorphic_xml_warchive: cw-9_5-darwin test_primitive_text_archive: vc-7_1 test_primitive_text_archive_dll: vc-7_1 test_private_ctor: cw-9_5-darwin test_registered_text_archive: vc-7_1 test_registered_text_archive_dll: vc-7_1 test_reset_object_address: cw-9_5-darwin test_set_binary_archive: cw-9_5-darwin test_set_binary_archive_dll: cw-9_5-darwin test_set_text_archive: cw-9_5-darwin test_set_text_warchive: cw-9_5-darwin test_set_xml_archive: cw-9_5-darwin test_set_xml_warchive: cw-9_5-darwin 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 test_split_text_archive: vc-7_1 test_split_text_archive_dll: vc-7_1 test_split_text_warchive: gcc-3_4_3-sunos test_tracking_text_archive: vc-7_1 test_tracking_text_archive_dll: vc-7_1 test_unregistered_binary_archive: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux test_unregistered_binary_archive_dll: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux test_unregistered_text_archive: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux vc-7_1 test_unregistered_text_archive_dll: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux vc-7_1 test_unregistered_xml_archive: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux test_unregistered_xml_archive_dll: gcc-3.2.3-linux gcc-4.0.1-linux intel-8.1-linux intel-9.0-linux test_unregistered_xml_warchive: gcc-4.0.1-linux test_unregistered_xml_warchive_dll: gcc-4.0.1-linux test_variant_binary_archive: cw-9_5-darwin test_variant_binary_archive_dll: cw-9_5-darwin test_variant_text_archive: cw-9_5-darwin test_variant_text_warchive: cw-9_5-darwin test_variant_xml_archive: cw-9_5-darwin test_variant_xml_warchive: cw-9_5-darwin test_vector_binary_archive: cw-9_5-darwin test_vector_binary_archive_dll: cw-9_5-darwin test_vector_text_archive: cw-9_5-darwin test_vector_text_warchive: cw-9_5-darwin test_vector_xml_archive: cw-9_5-darwin test_vector_xml_warchive: cw-9_5-darwin test_void_cast: gcc-3_4_3-sunos test_void_cast_dll: gcc-3_4_3-sunos |wave| testwave: gcc-3_4_3-sunos

1 0

Boost regression notification (2005-10-03 [HEAD])
by Douglas Gregor 03 Oct '05

03 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-03T05:00:21Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 120 failures in 9 libraries: concept_check (12) graph (2) mpl (1) parameter (11) serialization (30) spirit (8) thread (4) tuple (1) typeof (51) |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 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 |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 odr_native: 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

Is there any interest in a library which provides an extensible logging facility?
by Genia Bezman 03 Oct '05

03 Oct '05

The library would provide the ability to route a message, with an arbitary severity, to any amount of "sinks". The library would support any amount of loggers, identifiable by a unique name (std::string), so that the exact same logger would always be returned for a certain name. Sinks would be defined by deriving from an abstract Sink class. The library would provide a couple of premade sinks (file sink, console sink; ideas welcome). Any given logging message will use a derived class of an abstract Severity class to denote its severity. The library would provide some (8 or so) premade Severity subclasses. Possible syntax would be something like this: In some header file: FileSink fs("log.txt"); LOGGER("My Logger").tie(fs); In some source file: LOGGER << Warning << "Testing logger" << 42 << 3.4 << 'a' << endl; LOGGER(name) would be defined as something like Logger::instance(name, __LINE__, __FILE__) In addition, there would be a way to specify output formatting on a per-logger basis, ideas for possible syntax very welcome (maybe a printf-like syntax?) Any input is appreciated.

2 1

[mpl] sequence_wrapper change to handle enums
by Larry Evans 03 Oct '05

03 Oct '05

Would it be OK for me to copy: boost-sandbox/boost/mpl/aux_/sequence_wrapper.hpp to: boost/boost/mpl/aux_/sequence_wrapper.hpp for the reasons cited here: http://aspn.activestate.com/ASPN/Mail/Message/boost/2640803 ? Also, it would also help *nix developers if: boost-sandbox/libs/mpl/preprocessed/preprocess.py were similarly moved. OK to do that?

2 1

Database libraries - again
by Maciej Sobczak 03 Oct '05

03 Oct '05

Considering the fact that there was some interest in the database library, I think it is a good time to revive the discussion: ------- We are pleased to announce that the new version of SOCI library is available for download. http://soci.sourceforge.net/ The important new feature in the library allows to operate on whole arrays of values (interfaced via std::vector), which can greatly increase application performance by reducing network round-trips in those queries that insert or retrieve many rows at once. -------- I think that this feature is mandatory if we discuss a "quality" library. The question is how to interface to it and how much generic interface can be provided wrt so-called bulk operations. At the moment, SOCI supports interfacing via std::vector, for example: std::vector<int> vec; // ... sql << "insert into numbers(val) values(:val)", use(vec); or: vec.resize(100); // some batch size Statement st = (sql.prepare << "select val from numbers", into(vec)); st.execute(); while (st.fetch()) { // here, vec has subsequent portions of the whole result } Your comments are welcome. I would like to acknowledge that Steve Hutton entirely contributed to the implementation of the bulk operations in this new release. You can visit Steve at <http://featurecomplete.com/> -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

2 4

[serialisation] Optimisation
by Martin Slater 03 Oct '05

03 Oct '05

Hi there, I've been looking at speed issues loading archives for the last few days and came across something that puzzles me. We are using binary_archive's for storing relatively large data sets (> 100mg) comprised largely of std::vectors of pod types, this was causing huge inefficencies as for each element it was serialising it seperately so I derived a new archive type with specialisations for std::vector load/save that dispatches on podness (?) so if pod it just block writes/read the entire vector. This gave us a massive speedup so it could be useful to include this by default in the provided binary archive as the reaction of a number of our developers when first looking at vtune before this optimisation was that Boost.serialisation was just rubbish as it was so slow. (let me know if you want to see the implementation, its only about 100 lines or so). The next slowest thing as revealed by vtune is the call to basic_iarchive_impl::register_type and inparticular this code :- cobject_type co(cobject_info_set.size(), bis); std::pair<cobject_info_set_type::const_iterator, bool> result = cobject_info_set.insert(co); with the call to extended_type_info_typeid_0::less_than caused by the std::set::insert call consuming nearly 8% of the time needed to load the archive. Tracing this through revealed there seems to be some effort to optimise this call by using extended_type_info::type_info_key which is used by type_info_key_cmp (extended_type_info.cpp) to give an early out but this code if(lhs.type_info_key == rhs.type_info_key) return 0; in type_info_key_cmp always compares true (a breakpoint set after never gets hit) which then causes operator<(const extended_type_info &lhs, const extended_type_info &rhs) to eventually call type_info::before to give ordering information which is where the slowness comes from. This always returns true as it is just a pointer to class static data declared in extended_type_info_typeid_0. The comment attached to the member in extended_type_info states // used to uniquely identify the type of class derived from this one // so that different derivations of this class can be simultaneously // included in implementation of sets and maps. const char * type_info_key; but I cannot see how this will ever be different for any types. I get the impression that it is intended to be different for all types and the test is just relying on its address being unique per specialization of extended_type_info_typeid but I may be well off the mark, can anyone (Robert?) clarify this for me please. thanks Martin ps. This is using vc7.1 compiler.

1 1