On May 16, 2006, at 7:25 AM, Arunkumar wrote:
Hi Guys,
We are trying to find a good logging API and I came across log4cxx.
1) One of our main requirements is logging localized strings - i.e.
the
logger should understand UNICODE strings (TCHAR and LPTSTRs in win32
parlance) and log them correctly. I was looking at some of your
sample code
and all the examples use std::string. So is log4cxx Unicode
compatible and
do you have any examples for using the same?
Actually, the definition of TCHAR varies depending on the presence of
_MBCS (multibyte character string) or _UNICODE preprocessor macro.
If _MBCS is set, then TCHAR is defined as char and interpreted
according to the current code page (which would likely be Cp1252 for
Western European which close to ISO-8859-1 and a superset of US-
ASCII, but could also be any number of other code pages). If
_UNICODE is set, then TCHAR is defined as wchar_t ande interpreted
according as UTF-16.
The TCHAR and related stuff allowed you to take an application that
had a single character type and support building both an MBCS and
UNICODE build from the same source tree. The Win32 API exposed by
Win NT and later (and Win9x with Unicode) support consists of both
MBCS and UNICODE methods plus macros, something along the line of:
HRESULT LoadLibraryW(const wchar_t*);
HRESULT LoadLibraryA(const char*):
#if (_UNICODE)
#define LoadLibrary LoadLibraryW
#else
#define LoadLibrary LoadLibraryA
#endif
The use of the preprocessor macros for the generic LoadLibrary call
is necessary since the Win32 API is a C (not C++) API and you could
not do something like:
HRESULT LoadLibrary(const wchar_t*);
HRESULT LoadLibrary(const char*):
and have the compiler pick out the appropriate method.
For more info, see http://msdn2.microsoft.com/en-us/library/
c426s321.aspx
However since log4cxx is a C++ API and may be called from both
Unicode or MBCS executables in the same application, it exposes both
char and wchar_t methods in the public API. If it had used TCHAR in
its exposed methods (as log4cxx-0.9.7 did), you would have to build
log4cxx for either MBCS exclusively or UNICODE exclusively.
With the current approach, you can do:
TCHAR msg[] = _T("Hello, world");
LOG4CXX_DEBUG(logger, msg);
If you compile the module with _UNICODE, then the compiler will
select Logger::debug(const std::wstring&). If you compile the module
with _MSCS, then the compiler will will select Logger::debug(const
std::string&).
The internals of log4cxx use an single string type (LogString) which
is either wchar_t or char interpreted as UTF-8 regardless of current
code page.
To reiterate, if log4cxx's API were written in terms of TCHAR, a
log4cxx DLL would either expose either an exclusively MBCS API or an
exclusively UNICODE API and could not work with applications that
used a mix of MBCS and UNICODE code.
2) I tried to build log4cxx and hit a couple of roadblocks
especially with
cpptasks.jar and ant-contrib.jar. I tried a CVS checkout from the
ant-contrib project and it bombed. I searched the mailing list and
it seems
a few of us are having the same issue. Is it possible for you to
post the
necessary jar files needed for building log4cxx in your web site (I
need the
win32 version). This would make the build process more user
friendly. (I did
get the compiled win32 version from
http://littletux.homelinux.org/log4cxx/... but it is not the latest
one).
SourceForge has been having troubles with their CVS servers
recently. cpptasks is attempted to be built nightly by Gump and the
results can be downloaded from http://vmgump.apache.org/gump/public-
jars/cpptasks/jars/. I'm long overdue to get a formal cpptasks
release out and that is the right resolution to the problem.
