cvs commit: logging-log4cxx/include/log4cxx log4cxx.h

[ca...@apache.org]

carnold     2005/05/04 12:24:47

  Removed:     include/log4cxx log4cxx.h
  Log:
  Removing inadvertant generated config file

Re: cvs commit: logging-log4cxx/include/log4cxx log4cxx.h

[Curt Arnold <ca...@apache.org>]

If you can add a option to state a fixed locale character encoding and 
set a corresponding macro in log4cxx/private/log4cxx.h, that would be 
great.  That way if you knew that you were only going to be deploying 
where the locale character encoding was UTF-8, then conversion from 
locale charset to internal charset could just just memcpy's.

Something like --ctype=UTF-8 would get translated as

#define LOG4CXX_LOCALE_ENCODING_UTF8 1

The other possible recognized values would be US-ASCII and ISO-8859-1.  
Anything else would not be recognized and would require calling 
mbstowbs and then encoding as UTF-8.

Since most Linux distributions are UTF-8 now, perhaps it would be good 
that the default was fixed UTF-8 and you have to explicitly specify 
when you wanted to follow the locale declared encoding.

I don't know the conventions, I'll rely on your judgment or you can 
provide whatever examples for similar configurations you can find.



On May 7, 2005, at 12:06 AM, Curt Arnold wrote:

>>
>> About this, I have a problem with some ac variables you use in 
>> log4cxx.h.in
>> but which are not set by configure.in :
>> LOGCHAR_IS_UTF8 and HAS_WCHAR_T
>> How do you expect them to be defined ? Do I add some option to 
>> configure of do
>> I compute it from --enable-unicode ?

Re: cvs commit: logging-log4cxx/include/log4cxx log4cxx.h

[Curt Arnold <ca...@apache.org>]

>
> About this, I have a problem with some ac variables you use in 
> log4cxx.h.in
> but which are not set by configure.in :
> LOGCHAR_IS_UTF8 and HAS_WCHAR_T
> How do you expect them to be defined ? Do I add some option to 
> configure of do
> I compute it from --enable-unicode ?
>

Sorry, I forgot about that.  LOG4CXX_HAS_WCHAR_T should be detected.  
It indicates whether or not the compiler has a wchar_t type.  If it 
doesn't then, then all the API methods involving wchar_t would 
disappear.

LOG4CXX_LOGCHAR_IS_UTF8 indicates that LogString (the internal string 
type) is a std::string encoded in UTF-8.  Currently either 
LOG4CXX_LOGCHAR_IS_UTF8 or LOG4CXX_LOGCHAR_IS_WCHAR is 1 and the other 
0.  It is possible, but unlikely, that at some future date that other 
options for LogString would be provided.

Obviously if the compiler doesn't have a wchar_t then 
LOG4CXX_LOGCHAR_IS_WCHAR should be 0.  LOG4CXX_LOGCHAR_IS_UTF8 = 1 is 
likely the better value for the Unix's and LOG4CXX_LOGCHAR_IS_WCHAR = 1 
for Windows.  If you knew at compile time the locale charset would be 
UTF-8, a lot of the character encoding and decoding could be 
short-circuited to memcpy's.

I think you should add some option to configure.  Either option should 
support "unicode" except on a few platforms where wchar_t is a little 
weird, so --enable-unicode doesn't seem to fit.  On those few weird 
platforms LOG4CXX_LOGCHAR_IS_WCHAR = 1 should not be used since log4cxx 
expects that you can represent any string as std::basic_string<logchar> 
and it can be converted to a UCS-4 scalar value.

Changing the logchar totally breaks any binary compatibility, so it 
should be very rare to change it to something other than the platform 
default.  Probably should just leave it as LOGCHAR_IS_UTF 1 in the 
log4cxx.h.in and if you really want to change it, you can use the Ant 
build or we can add the option later.

Re: cvs commit: logging-log4cxx/include/log4cxx log4cxx.h

[Christophe de Vienne <cd...@apache.org>]

Le Jeudi 5 Mai 2005 18:06, Curt Arnold a écrit :
> They are both good and intended.  log4cxx/log4cxx.h contains typedef
> and defines that are visible to applications using log4cxx,
> log4cxx/private/log4cxx.h contains typedef and defines that are only
> visible to the log4cxx implementation.  log4cxx/private/log4cxx.h
> contains a #error, if it is used outside of the log4cxx implementation
> and test.

Allright.

>
> I'm not fixed on the names, I would have no problem with
> log4cxx/private/log4cxx.h being renamed log4cxx/log4cxx_private.h if
> that would make the distinction clearer.

It would be clearer indeed, but not that much.

> I would think that 
> log4cxx/log4cxx.h should not contain any automatically detected
> settings.

Totaly agree on that.

> Though it should respond to explicit build instructions 
> that, for example, change the internal character representation.

About this, I have a problem with some ac variables you use in log4cxx.h.in 
but which are not set by configure.in :
LOGCHAR_IS_UTF8 and HAS_WCHAR_T
How do you expect them to be defined ? Do I add some option to configure of do 
I compute it from --enable-unicode ?

Regards,

Christophe