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.
