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.