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.west...@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 >> >> >
