[ 
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)

Reply via email to