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 anythi
Eventually backwards compatibility has to be broken anyway. If the Level
changes, then that would be a good time to switch over to
standard(std/boost) smart pointers as well, which may break other code that
depends on Object. For the most part I don't think this will have a large
impact on librar
Guten Tag Peter Westman,
am Donnerstag, 27. Oktober 2016 um 11:11 schrieben Sie:
> My suggestion is to have getInfo return a const Level& instead of a
> LevelPtr.
But that would change the interface and "everyone" would need to change
things. On the other side, "const Level*" would at least be co
I think mixing smart pointers and static class allocation would just mix
things up. We should instead choose when to use one over the other.
We are currently returning new, dynamically allocated level objects for
each call to getInfo() etc. This memory must be freed. When logging from
a logger
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++1
Guten Tag Peter Westman,
am Donnerstag, 27. Oktober 2016 um 09:05 schrieben Sie:
> 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,
That should be thread-safe regarding LOGCXX-322 as well, shouldn't it?
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 re
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 understandi
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 disca
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
Guten Tag Peter Westman,
am Mittwoch, 26. Oktober 2016 um 08:48 schrieben Sie:
> Do you mind if I work on a
> solution for this and post it in LOGCXX-458 if I manage to create one?
458 is not the problem, 394 is why I changed things. So you need to
find another/better workaround to fix 394 withou
Reverting 1566655 solved the problems. I'd prefer not to have to tinker
with reverting/patching when building. Do you mind if I work on a
solution for this and post it in LOGCXX-458 if I manage to create one?
/Peter
On 10/25/2016 06:49 PM, Thorsten Schöning wrote:
Guten Tag Peter Westman,
am
Guten Tag Peter Westman,
am Dienstag, 25. Oktober 2016 um 14:40 schrieben Sie:
> Yes, its resource leaks.
Most of the leaks seem to have to do with levels, which were changed
by me because of problems in multi threading apps as well. Have a look
at the following bugs and try again with a reverted
Yes, its resource leaks. The 122 errors was from another logging.xml
then the one supplied in my example (it had an async appender in root,
with a file and console appender under it), with the example I sent it
is actually 22 errors (see below). The invalid free is most likely
something to do w
Guten Tag Peter Westman,
am Dienstag, 25. Oktober 2016 um 13:51 schrieben Sie:
> I get tons of valgrind errors (112 to be exact)[...]
I don't know valgrind very well, so what kind of errors are you
talking about? If it's resource leaks, some of those are known and
accepted to fix problems with mu
Hi,
First off, let me say that we've been using log4cxx for some years now
with great success. Its a wonderful library that really helps with
debugging and supporting code. Ive been using the log4cxx 0.10.0, but
upgraded to the svn trunk (r1755031) last week after having issues with
SocketHub
16 matches
Mail list logo
