Guten Tag Robert Middleton, am Donnerstag, 27. Oktober 2016 um 15:13 schrieben Sie:
> For the most part I don't think this > will have a large impact on library-using code, as at least in my > case I only use the LOG4CXX_level macros. I mostly only care about LoggerPtr myself and don't use anything else. So keeping LoggerPtr compatible/unchanged on the source level is something I would prefer, but should be possible unless the used smart pointer can't be derived from. > Perhaps it would be best to do a release of what currently exists > before the backwards compatibility is broken? Agreed and it's a shame, but I simply couldn't find the time yet to look into your changes to the release process and such. I'll try my best, in theory I have a holiday day on monday. But can't promise anything, sorry. It's company first... @Peter So, back to your original topic: Lets conclude that there's no other way to cleanly shutdown the lib and the current leak of memory is "by design" to fix the mentioned bugs by staying back compatible and users have to live with it for now. Additionally, I'll create two bugs, both mentioning this discussion: The first will be about changing the level interface like you have suggested to class statics with "const Level&" in the getters. This will fix your reported memory leak and will not introduce threading problems anymore, but break back compatibility, so it's deferred to a later version for now. The second is about replacing all ObjectPtr with boost|std::shared_ptr. I would prefer to not rely on autoconf or such to switch between both, simply because it's not easily available on Windows, changing the build tools has been discussed quite often etc. Only some simple macro which can be defined to either use boost- or std-prefix, with the latter being the default if nothing is set. If interested, I can create two branches named by the bugs, so people can provide patches against the concrete branches and I can commit them easily as work in progress. In theory Peter could even use the branch for the first bug to work with? You would at least not need to revert or patch anything manually. 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
