Re: ObjectPtrT question

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.