[jira] [Commented] (LOGCXX-486) Replace ObjectPtr with more standard shared_ptr.
[ https://issues.apache.org/jira/browse/LOGCXX-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255065#comment-17255065 ] Robert Middleton commented on LOGCXX-486: - I've updated a (new) proof-of-concept that all seems to be working. It is rather reliant on C++11 at this point, as it makes extensive use of std::shared_ptr, std::mutex, std::condition_variable, and std::thread. I'll keep the branch updated with master, until such time that we decide that it is ready to be merged in. > 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: > 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/%3C516ac3df-9119-3dc0-b7c7-5eba797a4ea5%40visualact.se%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOGCXX-486) Replace ObjectPtr with more standard shared_ptr.
[ https://issues.apache.org/jira/browse/LOGCXX-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16948802#comment-16948802 ] Thorsten Schöning commented on LOGCXX-486: -- bq. I didn't noticed it, sorry. My sentence should have said that I added the link after I read your question, because it was missing in fact. bq. Can you elaborate on "found things to be unnecessary complicated and stuff"? The currently implemented release process involving shell scripts and Maven etc. is complicated. At least some of those scripts are from me to automate steps formerly done manually, but there are still things which were broken. Have a look at `release_*` if you are interested, in the best case those should create a new tag and upload things to some dist-dev-repo in SVN used by Apache to vote on releases. Things like reverting version numbers in case additionally needed RCs, handle different tags/branches properly in those cases and stuff like that were still broken if I remember correctly. Besides those things the Apache-bureaucracy about releases is still somewhat unclear to me: Where to upload things when to vote on, where and how to upload which things after a successful vote, what to do in case of an unsuccessful one etc. I've already got to a point where I could upload some tagged RC created by the release-scripts, I think it was even signed with some PGP/GPG-key, but afterwards I wasn't able to proceed on when to put my keys where and voting and all that stuff. Priorities have changed since then and I simply had no time (and interest :-/) anymore to get things done again. http://www.apache.org/dev/release-publishing.html http://www.apache.org/legal/release-policy.html > 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: > 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/%3C516ac3df-9119-3dc0-b7c7-5eba797a4ea5%40visualact.se%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOGCXX-486) Replace ObjectPtr with more standard shared_ptr.
[
https://issues.apache.org/jira/browse/LOGCXX-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16948737#comment-16948737
]
Hreniuc Cristi commented on LOGCXX-486:
---
Thanks for taking the time to respond.
{quote}No, but there's a PoC at GitHub which I linked already:
[https://github.com/rm5248/log4cxx-testing/tree/smart_pointers]
{quote}
I didn't noticed it, sorry.
{quote}That's a decision you need to make on your own. I'm trying to take care
of input whenever I have the time to, simply because I use the lib on my own.
But it's unlikely currently that I will do major development. Feel free to join
the project and get things done.
[https://www.apache.org/foundation/getinvolved.html]
[https://community.apache.org/contributors/]
{quote}
I will think about this.
{quote}That's not my focus, I tried in the past and found things to be
unnecessary complicated and stuff.
{quote}
Can you elaborate on "found things to be unnecessary complicated and stuff"?
I'm just curious... Where there other people who were against it(meaning that
you can't thank everyone)? Is the codebase hard to modify without breaking
someone's code?
{quote}I'm the last left committer I guess, trying at least to provide some
level of support when possible.
{quote}
I asked this question, because I noticed that you are the only active person in
this project.
Again, thanks for taking the time to respond.
> 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:
> 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/%3C516ac3df-9119-3dc0-b7c7-5eba797a4ea5%40visualact.se%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LOGCXX-486) Replace ObjectPtr with more standard shared_ptr.
[ https://issues.apache.org/jira/browse/LOGCXX-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16948277#comment-16948277 ] Thorsten Schöning commented on LOGCXX-486: -- bq. Hey Thorsten Schöning were there any commits done for this task? I notice that it's been 3 years since this was opened. No, but there's a PoC at GitHub which I linked already: https://github.com/rm5248/log4cxx-testing/tree/smart_pointers bq. Is this project(log4cxx) still maintained? That's a decision you need to make on your own. I'm trying to take care of input whenever I have the time to, simply because I use the lib on my own. But it's unlikely currently that I will do major development. Feel free to join the project and get things done. https://www.apache.org/foundation/getinvolved.html https://community.apache.org/contributors/ bq. Will there be any other releases? That's not my focus, I tried in the past and found things to be unnecessary complicated and stuff. bq. What is your role in this project? I'm the last left committer I guess, trying at least to provide some level of support when possible. > 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: > 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/%3C516ac3df-9119-3dc0-b7c7-5eba797a4ea5%40visualact.se%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LOGCXX-486) Replace ObjectPtr with more standard shared_ptr.
[ https://issues.apache.org/jira/browse/LOGCXX-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16947911#comment-16947911 ] Hreniuc Cristi commented on LOGCXX-486: --- Hey [~tschoening] were there any commits done for this task? I notice that it's been 3 years since this was opened. > 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: > 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 (v8.3.4#803005)
[jira] [Commented] (LOGCXX-486) Replace ObjectPtr with more standard shared_ptr.
[ https://issues.apache.org/jira/browse/LOGCXX-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387761#comment-16387761 ] ASF GitHub Bot commented on LOGCXX-486: --- Github user tschoening commented on the issue: https://github.com/apache/logging-log4cxx/pull/2 There have been multiple discussions regarding CMake in the past, please search for them yourself on the mailing lists or in JIRA: https://markmail.org/search/?q=list%3Aorg.apache.logging.dev+cmake https://markmail.org/search/?q=list%3Aorg.apache.logging.log4cxx-dev+cmake https://logging.apache.org/log4cxx/latest_stable/mail-lists.html https://issues.apache.org/jira/browse/LOGCXX-486?jql=project%20%3D%20LOGCXX%20AND%20text%20~%20cmake > 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: > 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 (v7.6.3#76005)
