Yes, your fancy new cast function looks like a better approach. Should the note mention it uses the aliasing constructor std::shared_ptr or is it always going to be safe with log4cxx::Object pointers?
On Thu, Apr 22, 2021 at 7:54 AM Robert Middleton <osfan6...@gmail.com> wrote: > Yes, adding a note about casting would be a good idea. > > Note that there is a log4cxx::cast function that should handle this for you > - I believe that this is more reliable than using dynamic_cast, especially > across DLL boundaries. It should also properly do the shared_ptr > portion(so that you can have shared_ptrs of different types pointing at the > same object). > > -Robert Middleton > > On Wed, Apr 21, 2021 at 2:52 AM Stephen Webb <swebb2...@gmail.com> wrote: > > > Hi Robert, > > > > I suggest adding the following to 'change-report-gh.md' > > > > > > Migrating from 0.11.0 > > ----------------------------- > > > > Code changes are required for log4cxx pointer downcasting. The automatic > > cast performed by the log4cxx 0.11 smart pointer assign operator is no > > longer supported. > > > > For example: > > > > log4cxx::FileAppenderPtr fileAppender = > > log4cxx::Logger::getRootLogger()->getAppender(logAppender); > > if (fileAppender) > > fileAppender->getFile(); > > > > would become: > > > > auto appender = > > log4cxx::Logger::getRootLogger()->getAppender(logAppender); > > if (auto fileAppender = > > dynamic_cast<log4cxx::FileAppender*>(appender.get())) > > result = fileAppender->getFile(); > > > > > > On Tue, Apr 13, 2021 at 12:09 PM Robert Middleton <rmiddle...@apache.org > > > > wrote: > > > > > Before I go and do a release of log4cxx, are there any issues that may > > > need to be taken care of before the next release? Otherwise, if there > > > are no objections, I'll call for a release vote here shortly for > > > version 0.12.0. > > > > > > -Robert Middleton > > > > > >
