Questions about include/log4cxx/helpers/tchar.h

[Curt Arnold <ca...@houston.rr.com>]

Including include/log4cxx/helpers/tchar.h before the Win32 platform's 
tchar.h will result in compilation errors as the Win32 tchar.h's 
overrides the definitions of W2A, A2W, USES_CONVERSION etc.  These 
compilation errors can be avoided by forcing the Win32's tchar.h to be 
loaded first, but at least in my case both tchar.h's were loaded 
indirectly, it tooks some sleuthing to figure out where the Platform 
tchar.h needed to be added.

It doesn't appear that log4cxx itself uses some of the offending 
macros, so I'm assuming that the they were provided as a convenience 
for library users, however providing a second implementation of 
platform provided macros could be confusing, especially since the 
log4cxx implementation has length limitations that I don't believe 
exist in the Platform provided implementation.  For example, the 
message size limitation reported a few days ago, but be avoided by 
including the platform's tchar.h

I haven't really dug into this issue yet, but it did surprise me and 
maybe somebody could explain why the current state is a good thing.

Re: Questions about include/log4cxx/helpers/tchar.h

[Curt Arnold <ca...@houston.rr.com>]

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.

Re: Questions about include/log4cxx/helpers/tchar.h

[Michaël CATANZARITI <mc...@apache.org>]

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.

Curt Arnold wrote:
> Including include/log4cxx/helpers/tchar.h before the Win32 platform's 
> tchar.h will result in compilation errors as the Win32 tchar.h's 
> overrides the definitions of W2A, A2W, USES_CONVERSION etc.  These 
> compilation errors can be avoided by forcing the Win32's tchar.h to be 
> loaded first, but at least in my case both tchar.h's were loaded 
> indirectly, it tooks some sleuthing to figure out where the Platform 
> tchar.h needed to be added.
> 
> It doesn't appear that log4cxx itself uses some of the offending macros, 
> so I'm assuming that the they were provided as a convenience for library 
> users, however providing a second implementation of platform provided 
> macros could be confusing, especially since the log4cxx implementation 
> has length limitations that I don't believe exist in the Platform 
> provided implementation.  For example, the message size limitation 
> reported a few days ago, but be avoided by including the platform's tchar.h
> 
> I haven't really dug into this issue yet, but it did surprise me and 
> maybe somebody could explain why the current state is a good thing.
> 
> 
> 

-- 
Michaël CATANZARITI
log4cxx project manager

	log4cxx user mailing list:
	log4cxx-user-subscribe@logging.apache.org

	log4cxx developer mailing list:
	mailto:log4cxx-dev-subscribe@logging.apache.org