log4cxx and iostreams

[Ken Knox <ke...@gmail.com>]

Hi,
I'm investigating the posibility of using log4cxx in a middleware
product - the Java port of which already uses log4j. As we ship on
numerous platforms and because of the fact that we provide  libraries
which our customers link with, we have to make as few assumptions
about customer code as possible. In particular we cannot make
assumptions about customer use of classic or standard iostreams
(shipping two versions of libraries is not an option). Unfortunately
there is extensive use of iostreams in log4cxx which would be a show
stopper for using it (for us that is).
My question is - is there any plans to remove iostream dependencies
from log4cxx - or if not should we undertake to do so, would this
effort be likely to be accepted into the codebase, and an effort made
subsequently to keep log4cxx iostream free?
Thanks & Regards,
Ken.

Re: log4cxx and iostreams

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

On Oct 4, 2004, at 10:41 AM, Ken Knox wrote:
>
> My question is - is there any plans to remove iostream dependencies
> from log4cxx - or if not should we undertake to do so, would this
> effort be likely to be accepted into the codebase, and an effort made
> subsequently to keep log4cxx iostream free?
> Thanks & Regards,
> Ken.
>
>

I am not aware of any plans to do so and I don't recall any previous 
requests.

I have been making vague threats to get to my bug and enhancement list 
which might actually happen in the next few weeks as I complete another 
project.  One of them (the unicode rework) would likely result in 
pretty substantial changes to the code-base which would likely conflict 
with an independent iostream-free branch.

I would definitely prefer using the standard C++ library in the 
implementation instead of going back to the C RTL.  However, the header 
files don't do a great job of hiding implementation details from the 
clients.  Would it be acceptable if log4cxx used the standard C++ 
libraries internally as long as the client header files did not contain 
any iostream types?  If not what types of changes would you propose?

Re: log4cxx and iostreams

[Ken Knox <ke...@gmail.com>]

Hi,
> >> Could you not go with standard iostreams for log4cxx then?
no we couldn't go with standard iostreams as this would restrict
customers who are using classic iostreams
> I believe you can get around this limitation by using STLport iostreams
Introducing STDport is not ideal for us as it's a further 3rd party
lib which customers may also be using and adds further risk to version
clashes etc. This could be circumvented I know, but I also know people
here with strong opinions that the combined use of ??printf and a good
String/StringBuffer class with streaming operators is the only way to
go.
Our experience with providing libs to customers led us to remove
iostreams completely from our products as their presence led to far
too many build & packaging cimplications. I was hoping that this
experience was shared by log4cxx and it would be mutually beneficial
for us to remove them. Given that log4cxx doesn't provide a binary
distribution I can see why this isn't really an issue and so using
iostreams gives all the benifits without the (our) drawbacks.
Anyway thanks for all your time & input.
Regards,
Ken.

Re: log4cxx and iostreams

[Christopher Smith <x...@xman.org>]

Curt Arnold wrote:
>> Could you not go with standard iostreams for log4cxx then? I mean,  
>> given that iostreams tend to be entirely in headers, it seems like 
>> you  could compile log4cxx with an iostreams library independant of 
>> what  your customers have.
> At least for the Microsoft platform, you are not allowed to mix old and  
> standard iostream include files within a single executable or DLL.  See  
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ 
> vccore98/html/_core_differences_in_iostream_implementation.asp.

I believe you can get around this limitation by using STLport iostreams 
when you build log4cxx.

--Chris

Re: log4cxx and iostreams

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

> Could you not go with standard iostreams for log4cxx then? I mean,  
> given that iostreams tend to be entirely in headers, it seems like you  
> could compile log4cxx with an iostreams library independant of what  
> your customers have.
>

At least for the Microsoft platform, you are not allowed to mix old and  
standard iostream include files within a single executable or DLL.  See  
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ 
vccore98/html/_core_differences_in_iostream_implementation.asp.

However, it think it is possible for an old iostream using application  
to use a DLL that uses standard iostream as long as the API does not  
involve any iostream types and the API include files don't include any  
iostream headers.  I haven't had time to check it, but I think it is  
pretty likely that the API-level log4cxx include files likely include  
standard iostream library headers which would cause compile errors in  
calling applications that used old iostreams.

Re: log4cxx and iostreams

[Christopher Smith <x...@xman.org>]

Ken Knox wrote:
> I'm investigating the posibility of using log4cxx in a middleware
> product - the Java port of which already uses log4j. As we ship on
> numerous platforms and because of the fact that we provide  libraries
> which our customers link with, we have to make as few assumptions
> about customer code as possible. In particular we cannot make
> assumptions about customer use of classic or standard iostreams
> (shipping two versions of libraries is not an option). Unfortunately
> there is extensive use of iostreams in log4cxx which would be a show
> stopper for using it (for us that is).

Could you not go with standard iostreams for log4cxx then? I mean, given 
that iostreams tend to be entirely in headers, it seems like you could 
compile log4cxx with an iostreams library independant of what your 
customers have.

--Chris