- Boost - lists.boost.org

Boost.Logging: formal review
by Gennadiy Rozental 15 Nov '05

15 Nov '05

Hi, Being the author of at least 3 different solution for logging/tracing myself, I do believe it's one of the most important general purpose library in big project development. Unfortunately proposed submission in no way came close to being an acceptable choice. Numerous design and implementation issues, weak user and absent reference documentation and absent test suite (last two points is something that review manager is responsible for IMO. No tests or docs - no review. That's it) result in: My vote is NO. Please read further for detailed analysis. I. Design Flaws ------------------ 1. Filtering support I understand that author strived to minimize the solution, but IMO it lead to minimal value. IMO proper log system should support arbitrary user defined filtering of log entries. At the bare minimum it should support: entry level - levels set is ordered set of values indication importance of information provided. Filtering is based on threshold. Examples: DEBUG, INFO, MAJOR entry category - categories set is a set of unique values indicating kind of information provided Filtering is based on masking. Examples: ARGS, RETURN_VALUE, ERROR_LOG, DATA_FLOW, PROG_FLOW entry keyword - keyword set is set of user defined keywords (most frequently strings) identifying area of the program. Filtering is based on match of keywords. Keywords usually are used to mark specific part of application. Example: "NetworkLevel", "UI", "ABC" to mark class abc, "dfg.cpp" Also multithreaded application should support filtering based on thread id. The best solution would allow to plug-in at compile time any user defined Filter (in a form of Policy). This way I could have a log that filter nothing (no filters defined) or log that filter based on time of the day if I want. This submission does support level filtering - and that's it. 2. Configuration support Submitted solution supports configuration in a form of arbitrary modifiers that user could register in log. While this looks like very inflexible it's also as very inconvenient. In most cases I prefer log to be configured at run time from within configuration file. his would be very cumbersome with modifiers model. Not only each modifier needs to be added separately. I also need to keep track of it's name to be able to remove it and it's index to know how modifiers are ordered. This ability to configure log remotely in many locations makes it impossible to really know what and how is written into log. My preferred way to configure the log is with use of configuration string. First of all it's simplify an interface and you immediately see how your log entries going to look like. Here is an example: "keyword=*,-ACD;categ=prog_flow,return value,-details;l=debug;track=on;roll=10000;prefix=file ( line ) - time :;timeformat=%s:%m". Using pluggable factory pattern you could implement this to be as flexible. Eventually as an add-on you could provide an ability to register any custom modifiers, but that is not necessary in first draft. 3. Per output configuration. Log may have multiple appenders attached (BTW - I very much prefer term used by iostreams library - sink). what if I want different entry formatting/prefixing/filtering in different outputs. I may have errors_output which contains only errors. I may have end_user_log that contains only major information for end user with detailed time and date of the entry. And I may have developer_output that contains performance warnings with file and line information. Submitted library have no support for this. 4. Internationalization support I do see some vague traces in code that indicate that author new this needs to be supported. But since documentation have exactly zero information and I couldn't figure out how to do it myself, I assume that library doesn't support this. IMO it's required for industrial strength solution. 5. File and line This solution completely ignores file and line number of trace entry. IMO They are essential and should be collected for every entry (may not be reported - depends on prefix format) 6. Misfeature: pre-init cashing Library starts with cashing turned on to support pre-init logging. IMO this is too dangerous. Now developer needs to remember how many log entries are printed. Otherwise some of them will just start disappearing (could be different in every run). And it may start happening only at the user site. Much more reliable solution is to use some kind of startup log that does not require configuration. 7. Misfeature: log hierarchies I personally never have a need for that and have some difficulties to imagine why would anyone have. You could probably have it on top of existent solution as add-on. If it doesn't require any new interfaces (or some minimal addition). IMO library pays way to much attention to this. All these manipulate_logs(...) by name that is analyzed not needed. In my experience I never wonted to configure more than one log identically. And it's much more preferable to keep all the configuration of one log in one place. So I wouldn't look around to see what and how was configured. 8. Misfeature: compile-time log support As it clear from above IMO log is (almost) never always enabled (and in any case there is a way to implement this without any additional support). And always disabled log could be implemented on macro level. Based on this I believe all the compile_tile machinery employed by library is unnecessary and just complicate implementation 9. Interface IMO primary interface advertised by library should be macro-less. Documentation does need to cover how these macros needs to be written, but with user defined filters user will need to do the job oneself. Also in my experience I found that on some systems Even if( ... ) <actual log here> could be unsatisfactory from performance standpoint. I employ one global Boolean is_log_on flag to guard all my log entries. and it should be a part of these macros 10. Performance. I am not sure wheather it's design or implementation issue, but library does a lot of premature pessimizations, which could be avoided. See in more details bellow. II. Implementation flaws ------------------ 1. File appender hierarchy To implement custom rolling library employs inheritance. This is clear example where delegation would be much better choice. Single file_sink that could be initialized with file_roller. 2. Multithreading support implementation a) For some unclear reason author chose to reimplement some of Boost.Threads functionality in some places (and in some places Boost.Thread is used always). I believe log library shouldn't do this. b) I noticed some fishy construct (m_destroyed data member). It opens some thread safety issues IMO. c) static manager_type & manager() doesn't look thread safe. 3 . enabled_logger::m_stream For some reason enabled_logger allocates m_stream dynamically for each log entry. I do not see why we need to do this. Even more: why not reuse a single instance per thread? 4. collection in use appender_array and modifier_array are better be implemented using lists 5. exception support try { LOG << "aaa" << foo() } catch(...) { LOG << "exception" } This construct doesn't seems generate what is expected if foo() throws an exception 5. appender_array appender_array seems to be defined in 2 placed 6. Appenders copying. >From code it seems that each logger has its own copy of each appender. Why would we need that? If we do why all the appenders are so heavy? 7. #ifdef UNICODE #ifdef UNICODE are spread all over the code. It needs to be centralized 8. shared_memory.hpp This header refer to the library that is not part of boost yet. I don't think it should be part of this submission. 9. Time string cashing prepend_time and prepend_time_strf calls are not cashed. It's a lot of work for nothing. 10. write_msg locking write_msg shouldn't lock on appenders writing. Each appender should be locked independently instead. Documentation is better be commented by somebody else. I thing though : no reference docs whatsoever. As well as no test suite. Hope my comments were constructive. Regards, Gennadiy

4 18

Boost regression notification (2005-11-12 [HEAD])
by Douglas Gregor 15 Nov '05

15 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-12T06:00:12Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 225 failures in 13 libraries: concept_check (12) date_time (2) graph (2) io (1) mpl (1) python (56) serialization (30) spirit (8) thread (4) tr1 (73) tuple (1) typeof (18) xpressive (17) |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 |date_time| testwcustom_time_zone: mingw-3_4_2 testwposix_time_zone: mingw-3_4_2 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |python| andreas_beyer: vc-7_1 args: vc-7_1 auto_ptr: vc-7_1 back_reference: vc-7_1 ben_scott1: vc-7_1 bienstman1: vc-7_1 bienstman2: vc-7_1 bienstman3: vc-7_1 builtin_converters: vc-7_1 callbacks: vc-7_1 const_argument: vc-7_1 crossmod_exception: vc-7_1 data_members: vc-7_1 defaults: vc-7_1 dict: vc-7_1 docstring: vc-7_1 enum: vc-7_1 exception_translator: vc-7_1 extract: vc-7_1 implicit: vc-7_1 injected: vc-7_1 iterator: vc-7_1 keywords: vc-7_1 list: vc-7_1 long: vc-7_1 map_indexing_suite: vc-7_1 minimal: vc-7_1 multi_arg_constructor: vc-7_1 nested: vc-7_1 numpy: vc-7_1 object: vc-7_1 opaque: vc-7_1 operators: vc-7_1 pearu1: vc-7_1 pickle1: vc-7_1 pickle2: vc-7_1 pickle3: vc-7_1 pickle4: vc-7_1 pointer_vector: vc-7_1 polymorphism: vc-7_1 polymorphism2: vc-7_1 polymorphism2_auto_ptr: vc-7_1 properties: vc-7_1 raw_ctor: vc-7_1 return_arg: vc-7_1 shared_ptr: vc-7_1 slice: vc-7_1 staticmethod: vc-7_1 stl_iterator: vc-7_1 str: vc-7_1 test_pointer_adoption: vc-7_1 try: vc-7_1 tuple: vc-7_1 vector_indexing_suite: vc-7_1 virtual_functions: vc-7_1 wrapper_held_type: 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 |tr1| run_complex_overloads: gcc-2.95.3-linux std_run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux intel-win32-9_0 mingw-3_4_2 std_run_random: gcc-2.95.3-linux gcc-3.4.4-linux mingw-3_4_2 std_test_bind: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_boost: gcc-2.95.3-linux std_test_complex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_function: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_hash: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_mem_fn: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_reference_wrapper: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_shared_ptr: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_tr1_include: gcc-2.95.3-linux mingw-3_4_2 std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_complex: gcc-2.95.3-linux test_hash: gcc-2.95.3-linux test_ios: gcc-2.95.3-linux test_istream: gcc-2.95.3-linux test_iterator: gcc-2.95.3-linux test_limits: gcc-2.95.3-linux test_locale: gcc-2.95.3-linux test_ostream: gcc-2.95.3-linux test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_streambuf: gcc-2.95.3-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux tr1_remove_bounds_test: 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 intel-win32-9_0 mingw-3_4_2 vc-7_1 |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: 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 template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| misc1: mingw-3_4_2 test1: mingw-3_4_2 test2: mingw-3_4_2 test3: mingw-3_4_2 test3u: gcc-3_3-darwin test4: mingw-3_4_2 test4u: gcc-3_3-darwin test5: mingw-3_4_2 test5u: gcc-3_3-darwin test6: mingw-3_4_2 test6u: gcc-3_3-darwin test7: mingw-3_4_2 test8: mingw-3_4_2 test9: mingw-3_4_2 test9u: gcc-3_3-darwin test_cycles: mingw-3_4_2 test_non_char: mingw-3_4_2

3 2

[iostreams] bug: is_open() should be const
by Alberto Ganesh Barbati 14 Nov '05

14 Nov '05

Hi, [referring to latest CVS version] in both class templates boost::iostreams::detail::direct_streambuf and boost::iostreams::detail::indirect_streambuf, member function is_open() is not declared const. However, boost::iostreams::stream<>::is_open() is declared const, so it won't compile as it calls one the former on a data member. Therefore, either all three members are declared const or none of them. The all-const approach makes more sense, IMHO. HTH, Ganesh

3 5

[Boost-bugs] [ boost-Bugs-1353875 ] predicates without default constructor fail to compile (2)
by SourceForge.net 14 Nov '05

14 Nov '05

Bugs item #1353875, was opened at 2005-11-11 03:54 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=1353875&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: predicates without default constructor fail to compile (2) Initial Comment: The first time I submitted I forgot to check the box for uploading the zip archive... I want to draw your attention to a possible flaw in the implementation of the write_graphviz method from the Boost Graph Library. The current implementation uses the assignment operator for the vertex and edge iterators. This is natural, but some examples fail to compile with this version. The problem comes from the predicates witch don't have default constructors. When trying to assign a vertex iterator of a graph filtered with such a predicate, the compiler issues an error: C2512:'positive_edge_weight_pred<MyEdgeWeightMap>' : no appropriate default constructor available with [ MyEdgeWeightMap=EdgeWeightMapT ] If a small modification in the write_graphviz implementation is made (using copy constructors instead of assignement operators), the example compiles and runs sucesfully. I am using the Microsoft Visual C++ 7.1 compiler. In conclusion, I think that this modification should be made, as it grows the flexibility of the library and doesn't add any overhead. I have attached the example (main.cpp) and the patch for graphviz.hpp (graphviz.hpp.patch). My e-mail adress is pdumitrache(a)bphx.ro ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1353875&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

[variant] Bug in recursive_wrapper_fwd.hpp?
by Howard Hinnant 14 Nov '05

14 Nov '05

I've been tracking down an preprocessor warning involving the redefinition of BOOST_TT_AUX_BOOL_TRAIT_DEF1. It appears to me, in boost 1.33.0, that recursive_wrapper_fwd.hpp is misusing: #include "boost/type_traits/detail/bool_trait_def.hpp" The usual include pattern for this header is: // should be the last #include #include "boost/type_traits/detail/bool_trait_def.hpp" ... #include "boost/type_traits/detail/bool_trait_undef.hpp" But recursive_wrapper_fwd.hpp has: #include "boost/type_traits/detail/bool_trait_def.hpp" #include "boost/mpl/aux_/lambda_support.hpp" ... and no include for bool_trait_undef.hpp. Is that as intended? Thanks, Howard

1 0

Memory Leak problems on VC7.1 of code uses boost 1.33.0
by Vernucci, Anthony 14 Nov '05

14 Nov '05

I am running a program that links to boost_thread-vc71-mt-gd-1_33.lib. The following code is the main driver. #include <test_virtualnetwork.h> #include <test_stringglobbing.h> #include <test_internals.h> #include <test_networking.h> #include <boost/test/unit_test.hpp> using boost::unit_test::test_suite; #define _CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> struct leak_reporter { static leak_reporter instance; leak_reporter(){ _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); } ~leak_reporter(){ _CrtDumpMemoryLeaks(); // replaced by the above } }; leak_reporter leak_reporter::instance; test_suite* init_unit_test_suite( int, char* [] ) { test_suite* test= BOOST_TEST_SUITE( "Master Test Suite" ); test->add( new test_virtualnetwork ); test->add( new test_stringglobbing ); test->add( new test_internals ); test->add( new test_networking ); return test; } The output is: Detected memory leaks! Dumping objects -> {140} normal block at 0x003657A8, 24 bytes long. Data: < | > C0 CA 97 7C FF FF FF FF 00 00 00 00 00 00 00 00 {139} normal block at 0x003658F0, 8 bytes long. Data: < W6 > A8 57 36 00 01 CD CD CD Object dump complete. At MSDN I did read that if you #define _CRTDBG_MAP_ALLOC parameter, the memory leak dump will include the filename and line number info. But I did not get the file information even though I defined _CRTDBG_MAP_ALLOC. How do I get the filename and line number to display in the output? Thanks, - tony

1 0

Boost regression notification (2005-11-14 [RC_1_33_0])
by Douglas Gregor 14 Nov '05

14 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-14T13:59:09Z 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… 0 failure in 0 library:

1 0

Boost regression notification (2005-11-14 [HEAD])
by Douglas Gregor 14 Nov '05

14 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-14T06:00:47Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 197 failures in 14 libraries: concept_check (12) date_time (2) graph (2) io (1) math (5) mpl (1) python (56) serialization (30) spirit (8) thread (4) tr1 (52) tuple (1) typeof (18) xpressive (5) |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 |date_time| testwcustom_time_zone: mingw-3_4_2 testwposix_time_zone: mingw-3_4_2 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |math| complex_test: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 mingw-3_4_2 |mpl| size_t: gcc-4_0-darwin |python| andreas_beyer: vc-7_1 args: vc-7_1 auto_ptr: vc-7_1 back_reference: vc-7_1 ben_scott1: vc-7_1 bienstman1: vc-7_1 bienstman2: vc-7_1 bienstman3: vc-7_1 builtin_converters: vc-7_1 callbacks: vc-7_1 const_argument: vc-7_1 crossmod_exception: vc-7_1 data_members: vc-7_1 defaults: vc-7_1 dict: vc-7_1 docstring: vc-7_1 enum: vc-7_1 exception_translator: vc-7_1 extract: vc-7_1 implicit: vc-7_1 injected: vc-7_1 iterator: vc-7_1 keywords: vc-7_1 list: vc-7_1 long: vc-7_1 map_indexing_suite: vc-7_1 minimal: vc-7_1 multi_arg_constructor: vc-7_1 nested: vc-7_1 numpy: vc-7_1 object: vc-7_1 opaque: vc-7_1 operators: vc-7_1 pearu1: vc-7_1 pickle1: vc-7_1 pickle2: vc-7_1 pickle3: vc-7_1 pickle4: vc-7_1 pointer_vector: vc-7_1 polymorphism: vc-7_1 polymorphism2: vc-7_1 polymorphism2_auto_ptr: vc-7_1 properties: vc-7_1 raw_ctor: vc-7_1 return_arg: vc-7_1 shared_ptr: vc-7_1 slice: vc-7_1 staticmethod: vc-7_1 stl_iterator: vc-7_1 str: vc-7_1 test_pointer_adoption: vc-7_1 try: vc-7_1 tuple: vc-7_1 vector_indexing_suite: vc-7_1 virtual_functions: vc-7_1 wrapper_held_type: 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 |tr1| run_complex_overloads: gcc-2.95.3-linux std_run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_run_random: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_boost: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_complex: gcc-2.95.3-linux std_test_hash: gcc-2.95.3-linux std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_algorithm: gcc-2.95.3-stlport-4.6.2-linux test_complex: gcc-2.95.3-linux test_exception: gcc-2.95.3-stlport-4.6.2-linux test_hash: gcc-2.95.3-linux test_ios: gcc-2.95.3-linux test_istream: gcc-2.95.3-linux test_iterator: gcc-2.95.3-linux test_limits: gcc-2.95.3-linux test_locale: gcc-2.95.3-linux test_new: gcc-2.95.3-stlport-4.6.2-linux test_ostream: gcc-2.95.3-linux test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_streambuf: gcc-2.95.3-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tr1_remove_bounds_test: vc-7_1 |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: 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 template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| test3u: gcc-3_3-darwin test4u: gcc-3_3-darwin test5u: gcc-3_3-darwin test6u: gcc-3_3-darwin test9u: gcc-3_3-darwin

1 0

1.33.1 Final Release Plan
by Doug Gregor 14 Nov '05

14 Nov '05

Boost 1.33.1 Final will be released on December 5, 2005. Not "around" December 5, 2005; not "a week after" December 5, 2005; on December 5, 2005. As with the other releases in the 1.33.x series, it will come from the RC_1_33_0 branch. Minor bug fixes and documentation patches can be committed to the branch with my approval. If a change causes new failures, it will be reverted. A timeline: November 8: Boost 1.33.1 Beta released November 9: RC_1_33_0 open for bug fixes, documentation updates with prior approval November 28: RC_1_33_0 branch completely frozen. Final regression test results. December 2: Boost 1.33.1 release candidate. December 5: Boost 1.33.1 release. Doug

2 1

shared_ptr - allocator template argument
by Michael Schneider 14 Nov '05

14 Nov '05

Is there a reason why shred_ptr does not accept an allocator? shared_ptr seems to allocate sp_counted_impl_p<...> using new, it it took in an allocator, then the allocator could be assigned the responsibility to allocate the memory for sp_counter_impl_p. We have an application requirement that all application memory must be managed by our memory allocation system. We have a secondary requirement that we can't replace global new and delete. It seems like this requirement could be satisfied by adding an allocator to shared_ptr. I could make this change locally, but it seems like this would be a common requirement that would be useful for several application domains. Couple of quick questions: - am I off in the weeds with this suggestion? Is there a simple way to meet our memory requirement without modifying shared_ptr?? - If a change is required, what can I do to help make this change in boos (I am new to the boost community)? If this is not useful to the community, please let me know. I can code this in internal code if that is best for the boost community. Thanks Mike -- The greatest performance improvement occurs on the transition of from the non-working state to the working state.

3 2