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)
________________________
Barak Simon
GED IT Core Platform
190 George St. Sydney, 2000
Phone +61 2 925 85070
Fax +61 2 925 95050
[EMAIL PROTECTED]
g To:
[email protected]
cc:
22/12/2004 01:18 Subject: Re: ObjectPtrT
question
Please respond to
log4cxx-user
On Dec 21, 2004, at 6:35 AM, [EMAIL PROTECTED] wrote:
> Hi,
>
> I'm writing a custom appender for log4cxx, and have a few questions
> about the Object/ObjectImpl/ObjectPtrT classes.....Basically I'm going
> to code a number of classes that extend ObjectImpl, to make use of the
> ObjectPtrT "smart pointer" template and the Java-inspired threading
> methods, wait, notifiy, notifyAll (and I notice you have a semaphore
> imp...nice).
>
Actually, I've been removing the Java-inspired threading methods from
the underlying Object interface in the APR rework. Only a few classes
used the constructs but it required every object to carry around
mutexes and trying to precisely reproduce the Java threading semantics
is a non-trivial task.
> My question is a very general one.....what are the general rules of
> thumb you've been using when extending the ObjectImpl class?.... I've
> noticed the object macros (eg. casting ones), and will be including
> them in the declarations and implementations for my descendant
> classes. Can't say I'm entirely sure of the purpose of the cast method
> defined by the object class and implemented by the macros....is this
> just supposed to be a safe way of dynamically down-casting an
> object?....if so why was this method chosen in favour of the builtin
> dynamic_cast mechanism?...anyway, my C++ is good, but not exceptional
> (yet :-) ), so please excuse me if I've missed something here.
>
I can only speculate on the motivation since I wasn't in the project
when the code was originally written. The casting mechanism is an
attempt to do support safe down-casting and could have been written
using RTTI. I assume that RTTI was avoided since compiler support
varies and use of RTTI may have required code that used log4cxx be
compiled with RTTI enabled. It might be good to see if downcasting is
actually used within log4cxx, if not maybe those macros could be
stubbed out.
--
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
