ASF GitHub Bot commented on LOGCXX-486:
Github user tschoening commented on the issue:
There have been multiple discussions regarding CMake in the past, please
search for them yourself on the mailing lists or in JIRA:
> Replace ObjectPtr with more standard shared_ptr.
> Key: LOGCXX-486
> URL: https://issues.apache.org/jira/browse/LOGCXX-486
> Project: Log4cxx
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.11.0
> Reporter: Thorsten Schöning
> Priority: Major
> Fix For: 0.12.0
> To fix memory leaks in Levels in LOGCXX-485, we decided to change the API in
> back incompatible way and don't use LevelPtr anymore at all. If such a change
> is already made, this might be the best time to additionally remove ObjectPtr
> in favour of a more standard shared_ptr as well. In the end, the leak with
> Levels shouldn't have happened, because LevelPtr is a ObjectPtr and should
> take care of deleting allocated memory itself properly. Additionally,
> shared_ptrs in various implementations are really common these days, so there
> shouldn't be a need for a custom implementation anymore.
> So which shared_ptr to use? I suggest focussing on std with C\+\+11 and boost
> as a fallback for all users with older compilers and environments. We should
> create some kind of macro to make switching between both easy using some
> define and std might be a reasonable choice as default without any switch.
> This way modern C\+\+ environments don't introduce additional requirements.
> My own compiler C\+\+Builder XE10 from embarcadero e.g. is providing Boost
> 1.39 for its legacy compiler, which not yet supports C\+\+11 very well. The
> newer CLANG based ones on the other hand don't fully support some older
> legacy projects and libs, so supporting a Boost fallback should be a
> reasonable choice to not need to deal with a custom implementation. Boost
> itself should be so widespread used these days and 1.39 providing shared_ptr
> is so old, that it is most likely that all users of log4cxx can support it.
> The following was suggested on the mailing list as an example to switch
> between both:
> But I suggest not relying on autoconf anymore. We had quite some build tool
> discussions in the past, CMAKE has often been named as an alternative. It
> should be the easiest to simply define some macro which decides about the
> namespace to use, so the user can switch between boost and std or even
> std::tr1 and such manually by simply defining the macro. If it's undefined at
> compile time, std might be used as a fallback.
> This has been discussed in the following thread:
This message was sent by Atlassian JIRA