logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Middleton <osfan6...@gmail.com>
Subject Re: Cannot figure out how to clean correctly
Date Thu, 27 Oct 2016 08:46:49 GMT
Choosing between the smart pointers should be pretty straight forward:
http://stackoverflow.com/questions/7095556/how-to-handle-evolving-c-std-namespace-e-g-stdtr1shared-ptr-vs-std

This way people can use either a boost pointer or a C++11 pointer depending
on their compiler.  I only suggested C++11 since it's several years old at
this point and most people should be able to use the new features without
problems, but if it's possible to choose between C++11/boost that solves
the problem.

I think that the memory leak may be a consequence of how the Object class
is implemented; references must be incremented/decremented manually, which
could explain why the memory doesn't get freed.

-Robert Middleton

On Thu, Oct 27, 2016 at 3:05 AM, Peter Westman <peter.westman@visualact.se>
wrote:

> I think going for a boost::shared_ptr could be a good idea, most projects
> using something as complex as log4cxx should be able to cope with it imho.
> Another option would be to use some sort of ifndef rule to determine if
> boost or the current implementation is used.
>
> For levels though, I dont really see why we even have smart pointers? We
> could just as easily create the variables statically in the class, and use
> them as const references to the original levels. Right now the library is
> allocating new dynamic memory on a call basis, which seems pretty wasteful
> to me. If we make the storage static (which it was prior to
> LOG4CXX-394/r1566655 anyway). In some cases like the Logger class that
> stores a changeable level it would have to be a plain pointer, but I
> personally dont see a problem with that.
>
> /Peter
>
>
> On 10/27/2016 08:48 AM, Thorsten Schöning wrote:
>
>> Guten Tag Robert Middleton,
>> am Donnerstag, 27. Oktober 2016 um 01:39 schrieben Sie:
>>
>> 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.
>>>
>> That was my understanding as well, but than Valgrind shouldn't find
>> leaks?
>>
>> 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?
>>>
>> And what with all those non C++11 people out there? I'm using
>> Embarcadero C++Builder for example which doesn't support C++11 very
>> well with its legacy compiler and the new CLANG based ones are still
>> incompatible with some projects/environments. So at least I'm not that
>> interested to merge patches which make my life more difficult...
>>
>> How about boost::shared_ptr instead? It's no requirement currently,
>> but one might argue it's not that different than e.g. apr. In my
>> compiler at least boost 1.39 is provided, which would be enough for
>> shared_ptr, I'm using those already. 1.39 itself is so old, that it
>> might be a reasonable minimum requirement.
>>
>> Mit freundlichen Grüßen,
>>
>> Thorsten Schöning
>>
>>
>

Mime
View raw message