[
https://issues.apache.org/jira/browse/LOGCXX-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Schöning updated LOGCXX-486:
-------------------------------------
Description:
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>
was:
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>
> 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)
