RE: ObjectPtrT question

Hi Curt,

Good stuff. It looked like hard work using all those macros anyway. :-) I'll 
follow your lead and investigate using APR myself for handling threading issues.

One last thing....sorry if this has been asked recently already - I couldn't 
find any answers in the recent mail archives - but any idea when the next 
release will be out?

Thanks,
Jess

-----Original Message-----
From: Curt Arnold [mailto:carnold@xxxxxxxxxx]
Sent: 21 December 2004 14:19
To: Log4CXX User
Subject: Re: ObjectPtrT question



On Dec 21, 2004, at 6:35 AM, Jess.Morecroft@xxxxxxx 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.


Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.