logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: ObjectPtrT::operator-> const problem
Date Wed, 07 Nov 2007 23:10:11 GMT

On Nov 7, 2007, at 3:39 PM, Scott McCaskill wrote:

> I've noticed the const version of this method is returning a  
> pointer to const.  The reason this is a problem is that it makes it  
> impossible to log from const methods when LoggerPtr is a member  
> variable:
>
> class C
> {
>     public:
>         C() : logger(log4cxx::Logger::getLogger("my logger")) { }
>
>         void constMethod() const
>         {
>             // Error: can't do this because the const version of  
> ObjectPtrT::operator->()
>             // must be used, and it returns a pointer to const T.
>             LOG4CXX_DEBUG(logger, "debug message");
>         }
>
>     private:
>         log4cxx::LoggerPtr logger;
> };
>
> In both versions of operator->, the ObjectPtrT itself cannot be  
> modified, so it's not clear why there is a need for a non-const  
> version, or for a version that returns a pointer to const.  It  
> seems that in this case, the notion of pointer constness is being  
> conflated with the notion of pointee constness.
>
> Surely the above example is not such an unreasonable a thing to  
> expect to be able to do? :)
>
> BTW, I wasn't sure whether this was more appropriate for the user  
> list or the dev list (I'm subscribed to both).
>
> Scott McCaskill
>

log4cxx-dev is likely the more appropriate since things will quickly  
delve into minutiae that most users won't care to follow, but I think  
most people who could contribute subscribe to both.

I was around that code about a week ago and had the same reaction.  I  
did a naive quick fix on my local copy and everything fell apart, so  
I quickly reverted that change and moved on to other things.  I  
believe that const logging methods has been discussed before either  
on the list or in a bug report and might be something to research to  
see if any earlier discussion is helpful.

My quick gut reaction is:

a) your analysis is likely right

b) fixing it would likely require creating an alternative template  
that takes a pointer parameter, something like:

typedef log4cxx::helpers::ObjectPtrT2<const Logger*> ConstLoggerPtr;
typedef log4cxx::helpers::ObjectPtrT2<Logger*> LoggerPtr;

I wouldn't call it ObjectPtrT2, but I thought that was clearer for  
this discussion.

Changing the parameterization parameter for the existing template  
would have too much affect on client code.

c) Copying between pointer classes (for example, LoggerPtr,  
ConstLoggerPtr and ObjectPtrT<Logger>) would need to be supported as  
appropriate.

d) Methods that don't (obviously) change the state (logger->info()  
etc) would benefit from being const'd.

If anyone wants to play with it feel free and report back to the list.

Mime
View raw message