Hello, I have a class (below), and MS memory leak detector reports a leak on ptr.reset I have redefined 'new' as follows: #define MYDEBUG_NEW new( _NORMAL_BLOCK, __FILE__, __LINE__) In another example, also below I have an _impl structure that is allocated and assign to typedef boost::shared_ptr<cmoney_impl_dtl> t_money_storage; My understanding is that it is a 'false' detection is that correct? In otherwords, in my thinking -- as long as I have assigned an object to boost::shared_ptr -- I do not have remember anything about it anymore. (using visual studio 2008, 32 bit) Another question, since I have all of my heap objects using boost::shared_ptr is there any free tool that I can use to verify that those things do not leak (as some of the are actually DB connections so it is important for them to get completely destroyed). Thank you in advance ---------------------------- template <typename TThrdData> struct CService_ThreadData:private boost::noncopyable { CService_ThreadData (void){}; ~CService_ThreadData (void){}; ///creates a new thread data object if does not exists //Call this from every thread to establish thread's data //manager object static TThrdData& getdata(void) { /* YES, using static variable in this case is safe, because it is in the 'global' scope and therefore is intialized before Main starts Otherwise, static variables are not thread safe */ if (ptr.get() == 0) { ptr.reset(new TThrdData()); } return (TThrdData&)(*ptr); } private: static boost::thread_specific_ptr<TThrdData> ptr; };//end of class -------------------------- cmoney_t::cmoney_t (void) :v(new cmoney_impl_dtl) { } -- V S P toreason@fastmail.fm -- http://www.fastmail.fm - Access your email from home and the web
Hello vsp, The memory leak reported is probably because the static is detroyed after m$ standard dump kick in. Especially when linking against MFC, the dump may be forced to early which gives a lot of false positives in static objects. The trick is here to force MFc to link as early as possible, so that its static objects are destroyed as late asap. Further on shared_ptr's can still give memory leak, especially when creating cycles of shared_ptrs, but this seems not the case in your example.
participants (2)
-
gast128
-
V S P