[
https://issues.apache.org/jira/browse/LOGCXX-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15612625#comment-15612625
]
Thorsten Schöning commented on LOGCXX-486:
------------------------------------------
Should ObjectPtr get changed to be a subclass of default shared_ptr for back
compatibility reasons? This way we could implement special behaviour if needed.
Might just give it a try by completely removing or "typedef"ing ObjectPtr
without any customizations and see what breaks.
http://stackoverflow.com/questions/30309026/extending-shared-ptr-by-inheritance
> 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
> 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:
> http://stackoverflow.com/questions/7095556/how-to-handle-evolving-c-std-namespace-e-g-stdtr1shared-ptr-vs-std
> 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:
> http://mail-archives.apache.org/mod_mbox/logging-log4cxx-user/201610.mbox/<516ac3df-9119-3dc0-b7c7-5eba797a4ea5%40visualact.se>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
