On Dec 21, 2004, at 3:28 PM, Barak Simon wrote:
I am actually using both downcast and "invalid casts" checks (which returns NULL in the cast method) for my log4cxx-derived stuff
(e.g. my DBLogger customised class)
This enables me to detect whether a logger was created as a log4cxx::Logger or by using my DBFactory
(So I can call the correct forcedLog method which, alas, is not a virtual one)
My interim flushAll() method also relies on it for moving on the loggers' hierarchy, but then also using the cast to detect I am on the root logger
(which is of RootCategory class, that is, a sibling of my customised logger); another usage on the same method is for deciding if the current appender is derived from
WriterAppender, and if so, if it is a file or console appender.
But of course I can move to using dynamic_cast instead, if log4cxx moves to using it (and hence, adding the /GR flag on MSVC)
Thanks for the observation. I hadn't committed to anything and I haven't checked whether log4cxx downcasts internally. If it does, then I think that we are stuck with the macro based RTTI to avoid locking out apps that don't like standard C++ RTTI. However, if that facility is only used externally, rarely and by people who know they mucking with log4cxx internals and would use RTTI, then removing it (initially just dummying out the macros) may simplify log4cxx which is generally a good thing. There is much in the pipeline before this becomes an issue and will definitely revisit this on the list before proceeding.
