I haven't delved too deeply into the code(I don't have time today), but it looks like all that Object is doing is providing Java-like garbage collection in terms of memory management. A quick look at the SVN history indicates that the class was first created ~2003, so would it be worth it to discard Object entirely in favor of C++11 std::shared_ptr? It would be a rather large change but it may also fix many of the multithreading problems given the support for atomic operations on a shared_ptr. The only other thing that it provides is casting/instanceof operations, but the cast is never used and instanceof is used in ~6 places.
-Robert Middleton On Wed, Oct 26, 2016 at 4:39 AM, Thorsten Schöning <tschoen...@am-soft.de> wrote: > Guten Tag Thorsten Schöning, > am Mittwoch, 26. Oktober 2016 um 09:57 schrieben Sie: > > > 458 is not the problem, 394 is why I changed things. So you need to > > find another/better workaround to fix 394 without leaking. > > Another approach would be to first look at why LevelPtr doesn't seem > to delete not needed instances on app end. Creating new instances > itself shouldn't be the problem, especially if it fixes LOGCXX-394, > but I thought LevelPtr is taking care of deleting the created > instances when not needed anymore. > > So maybe just focus on LevelPtr, ObjectPtr and ObjectImpl first. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...........05151- 9468- 55 > Fax...............05151- 9468- 88 > Mobil..............0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > >
