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.
