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? https://issues.apache.org/jira/browse/LOGCXX-322 > and > use them as const references to the original levels. Do you suggest replacing LevelPtr as the return type of Level::get*? Because else we seem to need some LevelPtr as static base, because ObjectPtr-CTORs seem to only be capable of using raw pointers or ObjectPtrs. But if ObjectPtr leaks now, shouldn't it as well if used statically in the class? So one would need to find the reason for the leak anyway? Maybe we should enhance ObjectPtr to a mode for back compatibility reasons where a managed pointer is not deleted at all? This way the interface could stay the same and static levels instead of LevelPtrs could be used in the class. A new LevelPtr instance would be created on each invocation of Level::get*, though. > 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. 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
