logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@houston.rr.com>
Subject Re: Questions about include/log4cxx/helpers/tchar.h
Date Tue, 06 Jul 2004 06:56:41 GMT

On Jul 5, 2004, at 1:48 AM, Michaƫl CATANZARITI wrote:

> Hello Curt,
>
> These macros are defined in log4cxx because they don't exist on Unix 
> platforms.
> However I think they should not appear at the log4cxx library 
> interface, so the conflict will not exist anymore.
> It will be fixed in the next version.
>

I'd love to see any previous discussion on Unicode-related issues (I 
didn't see any on the log4cxx-user or log4cxx-dev mailing list).  Did 
log4cxx have mailing lists before it was an Apache project?

I have concerns about a couple of scenarios.

The first is an Unicode application using a third-party closed-source 
non-Unicode DLL where both the application and the DLL use log4cxx for 
logging.  These should be able to use the same log4cxx library.  If 
distinct log4cxx libraries are used, I'm pretty sure bad things will 
happen.

Logging a Unicode message that contains a character that is not 
representable in the current code page with a non-Unicode log4cxx 
implementation.  I'm not sure what the Platform W2A does in this 
scenario, it may return NULL or an uninitialized string.  Other 
conversion facilities may throw an exception.  Throwing an exception or 
failing to convert a log message would be undesirable.  However, given 
the intended audience reading the logs, it may be desirable to express 
unrepresentable characters using an escape sequence, so that if you had 
an log file with an ISO-8859-1 encoding and an Asian name was logged, 
you might get something a message with a lot of \u's in it, but it 
would still be useful.  However, it appears that log4j would fail to 
log a message under those conditions.

log4cxx appears to be using the preprocessor macro UNICODE to specify a 
Unicode build.  Win32 uses _UNICODE instead.  Having a distinct macro 
is probably a good thing, however it should be obviously distinct from 
the platform macro.  The Unicode configurations of MSVC projects look a 
little confused since they define both _MBCS and UNICODE resulting in 
_T("A") being a const char* if the Platform's tchar.h is included first 
and const wchar_t* if include/log4cxx/helpers/tchar.h is included. I'd 
recommend using obviously distinct macros like LOG4CXX_UNICODE and 
LOG4CXX_T("A") to prevent confusion with the platform equivalents.

My current preference would be to delay any conversion until the 
LoggingEvent constructor.  So you'd have (done without templates for 
clarity)

class Logger {
void debug(const char* msg, const char* file, int line);
void debug(const std::string& msg, const char* file, int line);
void debug(const wchar_t* msg, const char* file, int line);
void debug(const std::wstring& msg, const char* file, int line);
...
};

LoggingEvent could have four constructors and do any Unicode conversion 
there and use a consistent string representation for all the internals.


Mime
View raw message