I wrote this last night and forgot to send it. But then today didn't
go as I expected, so it can still act as a heads-up notice.
I'm planning on committing a fairly large change tomorrow. I had had
on my to-do list to add support for the Mac CoreFramework string
types. I thought I was going to do some quick little check to see
what would need to be changed and the changes kept rippling. I think
it is a good set of changes and cleans up a lot of old code. I've got
a few unit tests to finish off, so it will likely be mid-day tomorrow.
The essentials:
UniChar is an unsigned short containing UTF-16 values. UniChar
support does not depend on any additional libraries.
If LOG4CXX_HAS_UNICHAR is enabled, log4cxx methods that support
multiple string types support UniChar* and std::basic_strings.
If LOG4CXX_LOGCHAR_IS_UNICHAR is enabled, LogString is
std::basic_string<UniChar>.
If LOG4CXX_HAS_CFSTRING is enabled, log4cxx methods that support
multiple string types support CFStringRef. CFStringRef support does
depend on the CoreFoundation framework.
Ancillary changes:
Quite a few mismatch between string types on File constructors were
found which would result in LogStrings being passed when a string in
the current encoding was expected. Could result in mangled file names
when names included non-ASCII characters.
Cleaned up a lot of duplication and dead code in UnicodeHelper
(eliminated), Transcoder and CharsetEncoder and CharsetDecoder.
I'm pretty sure that log4cxx would misbehave on EBCDIC platform, but
have reduced the number of places that changes would need to be made.
I have no way of testing it, but I'm thinking that when I do the
commit, there will be some reasonable chance that it would work
properly on EBCDIC platforms.
