- Boost - lists.boost.org

Howto set SONAME (DLLVERSION)?
by Neal Becker 15 Nov '05

15 Nov '05

I want to set SONAME to 1.33, since 1.33.1 should be compatible with 1.33.0. Where/how can I set this?

6 8

[Boost-bugs] [ boost-Feature Requests-1357106 ] darwin 64 bit support
by SourceForge.net 15 Nov '05

15 Nov '05

Feature Requests item #1357106, was opened at 2005-11-15 05:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1357106&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: Ian Fasel (ianfasel) Assigned to: Nobody/Anonymous (nobody) Summary: darwin 64 bit support Initial Comment: To get 64-bit support, I was able to get a large chunk of boost-1_33_1 to build on darwin by inserting -arch ppc64 in strategic places in the darwin-tools.jam file. This was sufficient to be able to use the filesystem and program-options libraries in a 64-bit app I've built that needs to access > 4GB. Some libraries failed to build however, and I don't really know what I'm doing. Attached is a patch file showing what I added where. Also, it would probably be best to add -arch ppc -arch ppc64 to get "fat" binaries that work for both 32-bit and 64-bit code. However I'm no pro with these things. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1357106&group_… ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] "Re: serialization performance"
by bwood 15 Nov '05

15 Nov '05

On Mon, 14 Nov 2005 22:24:41 00100 (CET), bwood <brass_at_[hidden]> wrote: >> >> Either way, with or without the embedded flush code, Boost >> serialization is less efficient than Ebenezer's Send in both >> tests. >What are we comparing here? You really need to give the Boost commuinity >more visibility into your code if you expect your arguments to be taken >seriously. There is nothing on http://www.webebenezer.net that resembles >documentation or a complete test application that can be compiled. Hi, Caleb, I'm not sure if I understand your first question. I assume you read the previous posts. I compared the time it takes to serialize/send a list of ints using Boost and Ebenezer approaches. I timed the following Boost: oArch & lst; // using boost 1.33.0 Ebenezer: msgs.Send(buffer, lst); Without making any modifications to the two "vanilla" approaches, Boost takes more than twice as long than Ebenezer. On the surface, the two lines above look similar, but the Ebenezer line is flushing the buffer at the end of the Send function. So the Ebenezer side is doing more functionally in less time. (I've tested this by killing both test cases internally with a raise(9) right after the above lines. The Boost output file has 0 bytes in it. The Ebenezer file has all the data.) So in order to compare apples to apples, I #if 0ed out the flush code. In that case the Boost code is 7 times slower than the Ebenezer and both files have 0 bytes in them. If you want the code I used in these tests I will send it to you. It may be that gcc doesn't optimize the Boost code very well and another compiler would produce results that are better. The documentation is not very good. We hope to work on that. The "Send Sample" compiled last time I checked it. The code in the file MsgManager.h is generated by the site. It is not difficult to obtain that from the site. As far as build times, I agree that they aren't the most important factor. In my opinion they aren't trivial either. Brian

2 1

logging library link error
by Andrew Schweitzer 15 Nov '05

15 Nov '05

I just upgraded to the latest .zip file from John's web site. Now I can't seem to link. It can't find add_appender. This code built previously. Any idea what's going on? Am I not building the logging library correctly? I just cd to boot_root\libs\log\build, call "vcvars32.bat", then "bjam". It seems to build. If this line is uncommented: manipulate_logs("*").add_appender(write_to_cout); I get: AppMsg.obj : error LNK2019: unresolved external symbol "void __cdecl boost::logging::add_appender(struct boost::logging::default_log_manager &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class boost::function2<void,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::allocator<class boost::function_base> >,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,int)" (?add_appender@logging@boost@@YAXAAUdefault_log_manager@12@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$function2@XABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV12@V?$allocator@Vfunction_base@boost@@@2@@2@1H@Z) referenced in function "void __cdecl boost::logging::add_appender(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class boost::function2<void,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::allocator<class boost::function_base> >,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,int)" (?add_appender@logging@boost@@YAXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$function2@XABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV12@V?$allocator@Vfunction_base@boost@@@2@@2@0H@Z)

2 2

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