logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Schöning <tschoen...@am-soft.de>
Subject Re: Cannot figure out how to clean correctly
Date Thu, 27 Oct 2016 13:55:41 GMT
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.Schoening@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


Mime
View raw message