log4cpp-devel — technical discussions about the development of log4cpp

[Log4cpp-devel] Porting log4cpp to QNX Neutrino 6.1

[Harald W. <Har...@gm...>]

Hello again,

the short story is: log4cpp is running on QNX 6.1 without significant 
changes, and it passes all tests.

The long story: you may actually be wondering what the heck QNX is, and 
I do admit I had never heard of it until last year... It's a real-time 
embedded operating system, and a major player in that somewhat 
fragmented market. More details on www.qnx.com.

QNX does have some specialities, but it is more or less POSIX compatible 
and uses the gcc compiler suite, so you wouldn't expect any real trouble 
compiling any GNU compatible configure-make-install package.

The biggest issue is the fact that although they use gcc, it doesn't 
come with the GNU libstdc++ but with the Dinkumware libraries instead. I 
can't tell which of these two "Standard" C++ Library implementations is 
closer to the ISO C++ standard, but the fact is that most of the free 
stuff you get is developed on GNU, and most of it (going by the dozen or 
so packages I've tried) fails to compile against the Dinkum libs. To be 
fair, most of the errors are std:: namespace issues, and those are 
fairly easy to fix.

Now here's a summary of the changes I had to make:

- With the -pedantic compiler option, gcc gets so pedantic it refuses to 
compile anything at all, so I turned it off.

- Optimization -O2 produces internal compiler errors on some sources, so 
I removed that as well.

- gcc by default simply ignores the std:: namespace (at least in 
versions <= 2.95.3; I don't know about the most recent versions), but 
not in the QNX variant with the Dinkum libs. In most files, I had to 
insert "using namespace std;" or prefix a few function calls with std::.

- A similar problem is the syntax of standard C header includes. On QNX, 
you have to write #include <cstdio> instead of #include <stdio.h>, or 
you will get lots of symbol redefinition errors.

- The int64 stuff in PatternLayout doesn't compile, not even with the 
workaround, so I disabled it. Maybe there's a solution, I haven't looked 
at it closely.

- Some of the global Makefile settings are different, of course. The 
compiler and linker is called QCC, and you don't link any external 
libraries. pthread_* stuff is available by default.

- libtool refused to produce libraries. I installed a newer libtool 
version and I got archived libraries, but I haven't found out how to 
produce shared libs yet.


That's it, more or less. No big issues. I can post a patch for someone 
to review the changes, and if the community decides to accept them into 
the standard distribution, the final step (and for me, the most 
difficult one) would be to set up all the autoconf and automake input.
So far, I've simply edited the generated Makefiles, which is not the 
proper way, I know, but I have very limited experience with the auto* 
tools, and I find them rather hairy....

Any feedback is welcome!

Regards,
Harald

[Log4cpp-devel] Porting log4cpp to other platforms

[Harald W. <Har...@gm...>]

I'm new to this list, so let me say hello first of all.

I came across log4cpp when I was searching Sourceforge for a C++ logging 
library. I was familiar with log4j, so I was pleased to find a more or 
less 1:1 port of log4j in log4cpp, and personally, I prefer it over the 
other log4c* ports, but that may be a matter of taste.

Anyway, I think that excellent work has been done on this project so 
far, and maybe I could contribute a little to it, because log4cpp does 
not currently support all the platforms I'm working on, e.g. QNX and 
Windows CE.

This message is just a general question about the best way to contribute 
to log4cpp development and to add support for new platforms without 
interfering with any upcoming releases and, hopefully, without 
introducing new bugs ;-)

If this has been asked and answered before, please send me a link to the 
appropriate place.

I'm going to post two separate messages with my results and ideas so far 
for QNX and CE, assuming that different audiences will be interested in
these discussion threads.

Maybe someone else has started work on these platforms already. In that 
case, of course, I'd like to hook up with them.

Regards,
Harald

[Log4cpp-devel] Problem when Linking log4cpp 0.2.7 using SUN WS 6.1 CC

[xin h. x. <xh...@ya...>]

Hi, all,

   I encountered problem when I try to link testmain
of log4cpp-0.2.7 using Sun WorkShop 6.1 CC. Typical
errors displayed as below.

ild: (undefined symbol) void
std::vector<log4cpp::NDC::DiagnosticContext,std::allocator<log4cpp::NDC::DiagnosticContext>
>::__insert_aux(log4cpp::NDC::DiagnosticContext*,const
log4cpp::NDC::DiagnosticContext&) -- referenced in
../src/.libs/liblog4cpp.so

   I am sure somebody encountered this problem before.
please help. Thanks

best regards
xin hong



__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

[Log4cpp-devel] log4cpp 0.3.2 rc4 released

[Bastiaan B. <bas...@li...>]

Hi,

0.3.2rc4 is now available for download and testing. rc4 contains the
MSThreads.hh header missing from the previous release. Also the
compilation failure of rc2 has been resolved. 
This release passes make distcheck on the platforms I tested:
RedHat Linux 7.3 with gcc 2.96 and Limbo (RH pre 8.0) with gcc 3.2. 
If you encounter compile problems on other platforms please report them
through the bug tracker or the mailing list. 
Any other issues are welcome too of course, but I won't answer my mail
for the next two weeks, because I'll be on holiday.

Happy bug hunting,

Bastiaan
  

[Log4cpp-devel] 0.3.2 rc2 coming up

[Bastiaan B. <Bas...@li...>]

Hi, 

I will be on holiday the next two weeks, so I thought it would be a good
idea to release 0.3.2 rc2 before that. If there are no real showstoppers
at the moment I'll build it from the current revision, else holler
before tonight (GMT+01). 

This rc is intended to be the last before the real 0.3.2 release. If
noone has reported issues when I get back from holiday, I'll simply
rename it to 0.3.2.

Regards,

Bastiaan

 

Re: [Log4cpp-devel] Docs for win32 classes

[Bastiaan B. <Bas...@li...>]

On Tue, 2002-08-13 at 10:13, David Resnick wrote:
> Docs for classes NTEventLogAppender and Win32DebugAppender are not
> generated by doxygen because they are wrapped in "#ifdef WIN32". The
> documentation for them will be generated if 
> 
> PREDEFINED           = "WIN32"
> 
> is added to 'doc/Doxyfile'. 
> 
> I think this should be added for the general release (people not working
> on windows will ignore it).
> 

Yes, the documentation should be covering all components of log4cpp
regardless of whether the particular build platform supports them. 
However, if a component is not available on all platforms the
documentation of that component should contain a clear warning.

I've added the predefine and the warning in the two classes. 
While I was at it, I also added #error messages in case someone tries to
use these classes on the wrong platform. 
Should be a good idea for IdsaAppender and SyslogAppender too.

Regards,

Bastiaan


 

[Log4cpp-devel] Docs for win32 classes

[David R. <dre...@mo...>]

Docs for classes NTEventLogAppender and Win32DebugAppender are not
generated by doxygen because they are wrapped in "#ifdef WIN32". The
documentation for them will be generated if=20

PREDEFINED           =3D "WIN32"

is added to 'doc/Doxyfile'.=20

I think this should be added for the general release (people not working
on windows will ignore it).

Regards,

David Resnick
MobileSpear Inc.

Re: [Log4cpp-devel] Unbuffered FileAppender?

[Bastiaan B. <Bas...@li...>]

On Wed, 2002-08-07 at 13:51, Stuart Siegel wrote:
> Is there some way of emulating the effect of the setBufferedIO()
> method on the log4j FileAppender class in the log4cpp FileAppender
> class?
> 
> It seems like my debug messages that are being sent to a FileAppender
> are getting buffered and this is causing me some headaches when
> trying to track down the cause of a core dump.

Log4cpp does not have a setBufferedIO() equivalent at the moment.
But as a workaround you can open(2) the log file yourself with the
O_SYNC flag and pass the file descriptor to to FileAppender.

Regards,

Bastiaan
   
> 
> 
> =====
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] Unbuffered FileAppender?

[Stuart S. <ssi...@ya...>]

Is there some way of emulating the effect of the setBufferedIO()
method on the log4j FileAppender class in the log4cpp FileAppender
class?

It seems like my debug messages that are being sent to a FileAppender
are getting buffered and this is causing me some headaches when
trying to track down the cause of a core dump.


=====


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

[Log4cpp-devel] Doc make broken -> log4cpp/doc/mainPage.txt missing

[David R. <dre...@mo...>]

Missing file "@top_srcdir@/doc/mainPage.txt"

Regards,

David Resnick
MobileSpear Inc.

RE: [Log4cpp-devel] Version property sheet added to DLL

[David R. <dre...@mo...>]

As far as I can tell, the FileVersion string is not visible or even
accessible from anywhere; so we can safely just ignore it (I know, I
know -- so why is it there??). The binary FILEVERSION is accessible from
installation programs, etc. as well as being visible from the windows
explorer (which is why I added the property sheet). As for the strange
division into 2 or 4 integers... Beats me. The way it is currently setup
the version number is shown as "0.3.1.1".=20

I cleaned the resource file up a bit (threw away extra junk). I also did
some tests with adding extra fields and they seem to work just fine,
despite MS's mention of "predefined names". On the property sheet, the
description and copywrite as well as the first entry (alphabetically)
are immediately visible, the rest have to be selected to be seen. Also,
the description and copywrite should be short enough to fit on 1 line
(otherwise they need to be scrolled). I'll send you a jpg off list.

Thanks for the autoconf/automake pointers.

Regards,

David Resnick
MobileSpear Inc.

-----Original Message-----
From: David Resnick=20
Sent: Tuesday, August 06, 2002 08:27
To: 'Bastiaan Bakker'
Cc: log...@li...
Subject: RE: [Log4cpp-devel] Version property sheet added to DLL


There is a a description of the VERSIONINFO resource here:
http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/tools/=
r
c_7x2d.asp

The file version is in 4 separate entities in the binary format
(FILEVERSION). From the docs: Specifies the binary version number for
the file. The version consists of two 32-bit integers, defined by four
16-bit integers.

Could you please explain to me in a couple of words how template strings
(like @PACKAGE_VERSION@) are replaced (what tools are used, a sample
command line for doing it, where the replacement values come from)? How
do I generate the doxygen config file for example?

I used this project's VERSIONINFO as a base for the values I put in
log4cpp:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dqsd/dqsd/src/DQSDTools/D
QSDTools.rc?rev=3D1.24&content-type=3Dtext/vnd.viewcvs-markup

Sorry for dunking you in the doubly cold waters of lawyers and Microsoft
;-).

Regards,

David Resnick
MobileSpear Inc.

-----Original Message-----
From: Bastiaan Bakker [mailto:bas...@li...]=20
Sent: Monday, August 05, 2002 23:43
To: David Resnick
Cc: log...@li...
Subject: Re: [Log4cpp-devel] Version property sheet added to DLL


On Mon, 2002-08-05 at 08:45, David Resnick wrote:
> Hello,
>=20
> I've added a "version" property sheet to the DLL version of log4cpp.
>=20
> Bastiaan, please check the values in msvc6\log4cppDLL\log4cppDLL.rc.
> There are "legalese" type fields there that I filled in with what=20
> seemed to be correct values, but it is hard to tell...
>=20

Indeed it is. Is a definition of it's file format available somewhere?=20
Does the file version need to be three separate intities? It would be
convienent to template the file with @PACKAGE_VERSION@ in order to keep
the version number up to date. Also it would be nice to put the
copyright holders somewhere, since LifeLine and me aren't the only ones.
Maybe it's easiest to refer to the
(informal) 'the Log4cpp Project', but I not familiar enough with this
"legalese" stuff to know whether that's OK. But I guess this can simply
be added to the "LegalCopyright" field? Anyway the LGPL is the
definitive copyright statement for log4cpp...=20

Thanks,

Bastiaan
=20
=20
=20
> Regards,
>=20
> David Resnick
> MobileSpear Inc.
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf=20
> _______________________________________________
> Log4cpp-devel mailing list Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

RE: [Log4cpp-devel] Version property sheet added to DLL

[Bastiaan B. <Bas...@li...>]

On Tue, 2002-08-06 at 08:27, David Resnick wrote:
> There is a a description of the VERSIONINFO resource here:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/r
> c_7x2d.asp
> 
> The file version is in 4 separate entities in the binary format
> (FILEVERSION). From the docs: Specifies the binary version number for
> the file. The version consists of two 32-bit integers, defined by four
> 16-bit integers.
> 

Aarrggh. I'm already sorry I asked. This description page only leaves
you with more questions:

Why are there two FILEVERSION parameters? 
Why do you have to specify the first one as four 16-bit integers if they
are 'two 32-bit integers'?
What is the meaning of these integers? Are they used somewhere else
(e.g. for version compatiblity checking)?
What's the use of the second FILEVERSION parameter if you can get the
file version from the first one already?
The second parameter appears to want the version as a single string,
like "0.3.2rc2". How are you supposed to map that to the four 16-bit
integers?


> Could you please explain to me in a couple of words how template strings
> (like @PACKAGE_VERSION@) are replaced (what tools are used, a sample
> command line for doing it, where the replacement values come from)? How
> do I generate the doxygen config file for example?

It's part of the GNU autoconf/automake tools: the template substitution
if performed in the AC_OUTPUT m4 macro at the end of ./configure. I
guess the easiest way of doing the same on MSWindows is tool install
Cygwin, autoconf 2.5x and automake 1.6 and run configure yourself. 
BTW doing the template substitution would not be necessary to compile
log4cpp from a dist tar ball, as it would already contain the filled in
template. But Win32 developers working from CVS would have to generate
the .rc file from the .rc.in file. 
  
> 
> I used this project's VERSIONINFO as a base for the values I put in
> log4cpp:
> 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dqsd/dqsd/src/DQSDTools/D
> QSDTools.rc?rev=1.24&content-type=text/vnd.viewcvs-markup
> 

Ah, OK. I see the also have a 'ContributingAuthors' parameter. But from
the Microsoft page I get the impression that adding your own parameter
names is not allowed?

> Sorry for dunking you in the doubly cold waters of lawyers and Microsoft
> ;-).

I take it as the ice cold plunge bath in the sauna: for a few seconds
the temparature difference activates your body, but then you run for
quickest way to get out of it :-)

Cheers,

Bastiaan

> 
> Regards,
> 
> David Resnick
> MobileSpear Inc.
> 
> -----Original Message-----
> From: Bastiaan Bakker [mailto:bas...@li...] 
> Sent: Monday, August 05, 2002 23:43
> To: David Resnick
> Cc: log...@li...
> Subject: Re: [Log4cpp-devel] Version property sheet added to DLL
> 
> 
> On Mon, 2002-08-05 at 08:45, David Resnick wrote:
> > Hello,
> > 
> > I've added a "version" property sheet to the DLL version of log4cpp.
> > 
> > Bastiaan, please check the values in msvc6\log4cppDLL\log4cppDLL.rc. 
> > There are "legalese" type fields there that I filled in with what 
> > seemed to be correct values, but it is hard to tell...
> > 
> 
> Indeed it is. Is a definition of it's file format available somewhere? 
> Does the file version need to be three separate intities? It would be
> convienent to template the file with @PACKAGE_VERSION@ in order to keep
> the version number up to date. Also it would be nice to put the
> copyright holders somewhere, since LifeLine and me aren't the only ones.
> Maybe it's easiest to refer to the
> (informal) 'the Log4cpp Project', but I not familiar enough with this
> "legalese" stuff to know whether that's OK. But I guess this can simply
> be added to the "LegalCopyright" field? Anyway the LGPL is the
> definitive copyright statement for log4cpp... 
> 
> Thanks,
> 
> Bastiaan
>  
>  
>  
> > Regards,
> > 
> > David Resnick
> > MobileSpear Inc.
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf 
> > _______________________________________________
> > Log4cpp-devel mailing list Log...@li...
> > https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
> 
> 

RE: [Log4cpp-devel] Version property sheet added to DLL

[David R. <dre...@mo...>]

There is a a description of the VERSIONINFO resource here:
http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/tools/=
r
c_7x2d.asp

The file version is in 4 separate entities in the binary format
(FILEVERSION). From the docs: Specifies the binary version number for
the file. The version consists of two 32-bit integers, defined by four
16-bit integers.

Could you please explain to me in a couple of words how template strings
(like @PACKAGE_VERSION@) are replaced (what tools are used, a sample
command line for doing it, where the replacement values come from)? How
do I generate the doxygen config file for example?

I used this project's VERSIONINFO as a base for the values I put in
log4cpp:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dqsd/dqsd/src/DQSDTools/D
QSDTools.rc?rev=3D1.24&content-type=3Dtext/vnd.viewcvs-markup

Sorry for dunking you in the doubly cold waters of lawyers and Microsoft
;-).

Regards,

David Resnick
MobileSpear Inc.

-----Original Message-----
From: Bastiaan Bakker [mailto:bas...@li...]=20
Sent: Monday, August 05, 2002 23:43
To: David Resnick
Cc: log...@li...
Subject: Re: [Log4cpp-devel] Version property sheet added to DLL


On Mon, 2002-08-05 at 08:45, David Resnick wrote:
> Hello,
>=20
> I've added a "version" property sheet to the DLL version of log4cpp.
>=20
> Bastiaan, please check the values in msvc6\log4cppDLL\log4cppDLL.rc.=20
> There are "legalese" type fields there that I filled in with what=20
> seemed to be correct values, but it is hard to tell...
>=20

Indeed it is. Is a definition of it's file format available somewhere?=20
Does the file version need to be three separate intities? It would be
convienent to template the file with @PACKAGE_VERSION@ in order to keep
the version number up to date. Also it would be nice to put the
copyright holders somewhere, since LifeLine and me aren't the only ones.
Maybe it's easiest to refer to the
(informal) 'the Log4cpp Project', but I not familiar enough with this
"legalese" stuff to know whether that's OK. But I guess this can simply
be added to the "LegalCopyright" field? Anyway the LGPL is the
definitive copyright statement for log4cpp...=20

Thanks,

Bastiaan
=20
=20
=20
> Regards,
>=20
> David Resnick
> MobileSpear Inc.
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf=20
> _______________________________________________
> Log4cpp-devel mailing list Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

Re: [Log4cpp-devel] Version property sheet added to DLL

[Bastiaan B. <bas...@li...>]

On Mon, 2002-08-05 at 08:45, David Resnick wrote:
> Hello,
> 
> I've added a "version" property sheet to the DLL version of log4cpp.
> 
> Bastiaan, please check the values in msvc6\log4cppDLL\log4cppDLL.rc.
> There are "legalese" type fields there that I filled in with what seemed
> to be correct values, but it is hard to tell...
> 

Indeed it is. Is a definition of it's file format available somewhere? 
Does the file version need to be three separate intities? It would be
convienent to template the file with @PACKAGE_VERSION@ in order to keep
the version number up to date.
Also it would be nice to put the copyright holders somewhere, since
LifeLine and me aren't the only ones. Maybe it's easiest to refer to the
(informal) 'the Log4cpp Project', but I not familiar enough with this
"legalese" stuff to know whether that's OK. But I guess this can simply
be added to the "LegalCopyright" field? Anyway the LGPL is the
definitive copyright statement for log4cpp... 

Thanks,

Bastiaan
 
 
 
> Regards,
> 
> David Resnick
> MobileSpear Inc.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] Version property sheet added to DLL

[David R. <dre...@mo...>]

Hello,

I've added a "version" property sheet to the DLL version of log4cpp.

Bastiaan, please check the values in msvc6\log4cppDLL\log4cppDLL.rc.
There are "legalese" type fields there that I filled in with what seemed
to be correct values, but it is hard to tell...

Regards,

David Resnick
MobileSpear Inc.

[Log4cpp-devel] RollingFileAppender, NTEventLogAppender and threshold attrib. for appender added to PropertyConfigurator

[David R. <dre...@mo...>]

Regards,

David Resnick
MobileSpear Inc.

Re: [Log4cpp-devel] multithread question

[Bastiaan B. <bas...@li...>]

Hi Emiliano,

Thanks for the contribution. It has been committed, together with some
crude m4 stuff to add a '--with-pthreads' option to ./configure.
On RH Linux 7.3 this builds and passes 'make check' without problems. Of
course the 'tests' directory does not contain any concurrency checks
yet. Any volunteers to write some? =20
Now if I only finish the PropertyConfigurator stuff we can push 0.3.2
out the door.

Cheers,

Bastiaan Bakker
LifeLine Networks bv

On Thu, 2002-08-01 at 21:34, Emiliano Martin wrote:
> Hi:
>=20
> I'd like the idea, and i have done. This is a a Pthread implementation.=20
> I've tested with a multithreaded
> program that i'm developing and seems to be ok, i expect it's ok with=20
> the philosofpy of log4cpp.
> Any suggestion or thing you think must be changed, tell me please.
> I expect new version be soon released.
>=20
> Regards,
>=20
> Emiliano Mart=EDn
>=20
>=20
> Bastiaan Bakker wrote:
>=20
> >Hi Emiliano,
> >
> >log4cpp 0.2.x does not explicitly support multithreading.
> >But with some restrictions it still can be used in a multithreading
> >environment:
> >* don't change your logging configuration when you have multiple threads
> >running. In most cases you'll setup your Category hierarchy before the
> >application starts logging anyway, so this is not a large problem. Calls
> >to setPriority() are still permitted.
> >* The append function must be atomic. Log4cpp's appenders have been
> >written in a way that requires only 1 call to the underlying system to
> >write a log message (i.e. a single write() for the FileAppender). If
> >your OS handles this atomically, the logfile will be OK. Otherwise you
> >could end up with intertwined log messages. The latter appears to be the
> >case at least with OstreamAppender on Win32 platforms.
> >
> >If you want to have full MT support, you'll be happy to know that as of
> >version 0.3.0 log4cpp includes code for multithreading. Currently
> >(release 0.3.2rc1) it supports Omnithreads and Win32 threads, but
> >support for POSIX threads should not be too difficult to add: it
> >requires an adapter implementation for a simple Mutex, ScopedLock and
> >ThreadLocalData. You're very welcome to help in this area, if you like.
> >
> >Regards,
> >
> >Bastiaan Bakker
> >LifeLine Networks bv
> > =20
> >
> >On Tue, 2002-06-18 at 18:05, Emiliano Martin wrote:
> > =20
> >
> >>Hi:
> >>
> >>I've read log4ccp does not suppport multithreading,  can i do something=
=20
> >>like this to assure atomic access=BF=BF
> >>or it's very restrictive?? (or stupid)
> >>
> >>
> >>void Category::_logUnconditionally(Priority::Value priority,
> >>                                      const char* format,
> >>                                      va_list arguments) throw() {
> >>       OstringStream messageBuffer;
> >>
> >>       pthread_mutex_lock(writeMutex);
> >>       messageBuffer.vform(format, arguments);
> >>       _logUnconditionally2(priority, messageBuffer.str());
> >>       pthread_mutex_unlock(writeMutex);
> >>   }
> >>          =20
> >>thanks in advance
> >>
> >>
> >>-----------------------------------------------------------------------=
-----
> >>                   Bringing you mounds of caffeinated joy
> >>                      >>>     http://thinkgeek.com/sf    <<<
> >>
> >>_______________________________________________
> >>Log4cpp-devel mailing list
> >>Log...@li...
> >>https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
> >>   =20
> >>
> >
> >
> >
> > =20
> >
>=20
> ----
>=20

> /*
>  * PThreads.hh
>  *
>  * Copyright 2002, Emiliano Martin emi...@te... All rights reserve=
d.
>  *
>  * See the COPYING file for the terms of usage and distribution.
>  */
>=20
> #ifndef _LOG4CPP_THREADING_PTHREADS_HH
> #define _LOG4CPP_THREADING_PTHREADS_HH
>=20
> #include <log4cpp/Portability.hh>
> #include <stdio.h>
> #include <pthread.h>
> #include <string>
> #include <assert.h>
>=20
>=20
> namespace log4cpp {
> namespace threading {
>=20
> /**=20
>  * returns the thread ID
>  **/
>  static std::string getThreadId()=20
> {
> 	char buffer[16];
>        	sprintf(buffer, "%ld", pthread_self());
>         return std::string(buffer);    =20
> }
>        =20
> /**
>  **/
> class Mutex=20
> {
> 	private:
> 		pthread_mutex_t mutex;
>=20
> 	public:
> 		inline Mutex()
> 		{
> 			pthread_mutex_init(&mutex, NULL);
> 		}
>=20
> 		inline void lock()
> 		{
> 			pthread_mutex_lock(&mutex);
> 		}
>=20
> 		inline void unlock()
> 		{
> 			pthread_mutex_unlock(&mutex);
> 		}
>=20
> 		inline ~Mutex()
> 		{
> 			pthread_mutex_destroy(&mutex);
> 		}
>=20
> 		inline void operator=3D(const Mutex &m)
> 		{
> 			mutex =3D m.mutex;
> 		}
> };
>=20
> /**
>  *	definition of ScopedLock;
>  **/
> class ScopedLock
> {
> 	private:
> 		Mutex _mutex;
>=20
> 	public:
> 		inline ScopedLock(const Mutex &mutex)=20
> 		{=20
> 			_mutex =3D mutex;=20
> 			_mutex.lock();
> 		}
>=20
> 		inline ~ScopedLock()=20
> 		{
> 			_mutex.unlock();
> 		}
> };
>=20
> /**
>  *=20
>  **/
> template<typename T> class ThreadLocalDataHolder=20
> {
> 	private:           =20
> 	  	pthread_key_t _key;             =20
>=20
>         public:
>            	typedef T data_type;
>=20
>             	inline ThreadLocalDataHolder()=20
> 		{
> 			pthread_key_create(&_key, freeHolder);        =20
> 	    	}
>=20
>             	inline static void freeHolder(void *p)
> 		{
> 			assert(p !=3D NULL);
> 			T *data =3D (T *) p;
> 			delete p;
> 		}
>=20
>             	inline ~ThreadLocalDataHolder()=20
> 		{
> 			T *data =3D get();
>                 	if (data !=3D NULL)
> 			{=20
>                     		delete data;
> 			}
> 			pthread_key_delete(_key);
>             	}
>            =20
>             	inline T* get() const=20
> 	    	{
>                 	return (T *) pthread_getspecific(_key);=20
>             	}
>=20
>             	inline T* operator->() const { return get(); }
>             	inline T& operator*() const { return *get(); }
>=20
>             	inline T* release()=20
> 	    	{
>                 	T* result =3D get();
> 			pthread_setspecific(_key, NULL);=20
>=20
>                 	return result;
>             	}
>=20
>             	inline void reset(T* p =3D NULL)=20
> 		{
> 			T *data =3D get();
>                 	if (data !=3D NULL)=20
> 			{
>                     		delete data;
> 			}
> 			pthread_setspecific(_key, p);=20
>             	}
> };
>=20
> }
> }
> #endif

Re: [Log4cpp-devel] multithread question

[Emiliano M. <emi...@te...>]

Hi:

I'd like the idea, and i have done. This is a a Pthread implementation. 
I've tested with a multithreaded
program that i'm developing and seems to be ok, i expect it's ok with 
the philosofpy of log4cpp.
Any suggestion or thing you think must be changed, tell me please.
I expect new version be soon released.

Regards,

Emiliano Martín


Bastiaan Bakker wrote:

>Hi Emiliano,
>
>log4cpp 0.2.x does not explicitly support multithreading.
>But with some restrictions it still can be used in a multithreading
>environment:
>* don't change your logging configuration when you have multiple threads
>running. In most cases you'll setup your Category hierarchy before the
>application starts logging anyway, so this is not a large problem. Calls
>to setPriority() are still permitted.
>* The append function must be atomic. Log4cpp's appenders have been
>written in a way that requires only 1 call to the underlying system to
>write a log message (i.e. a single write() for the FileAppender). If
>your OS handles this atomically, the logfile will be OK. Otherwise you
>could end up with intertwined log messages. The latter appears to be the
>case at least with OstreamAppender on Win32 platforms.
>
>If you want to have full MT support, you'll be happy to know that as of
>version 0.3.0 log4cpp includes code for multithreading. Currently
>(release 0.3.2rc1) it supports Omnithreads and Win32 threads, but
>support for POSIX threads should not be too difficult to add: it
>requires an adapter implementation for a simple Mutex, ScopedLock and
>ThreadLocalData. You're very welcome to help in this area, if you like.
>
>Regards,
>
>Bastiaan Bakker
>LifeLine Networks bv
>  
>
>On Tue, 2002-06-18 at 18:05, Emiliano Martin wrote:
>  
>
>>Hi:
>>
>>I've read log4ccp does not suppport multithreading,  can i do something 
>>like this to assure atomic access¿¿
>>or it's very restrictive?? (or stupid)
>>
>>
>>void Category::_logUnconditionally(Priority::Value priority,
>>                                      const char* format,
>>                                      va_list arguments) throw() {
>>       OstringStream messageBuffer;
>>
>>       pthread_mutex_lock(writeMutex);
>>       messageBuffer.vform(format, arguments);
>>       _logUnconditionally2(priority, messageBuffer.str());
>>       pthread_mutex_unlock(writeMutex);
>>   }
>>           
>>thanks in advance
>>
>>
>>----------------------------------------------------------------------------
>>                   Bringing you mounds of caffeinated joy
>>                      >>>     http://thinkgeek.com/sf    <<<
>>
>>_______________________________________________
>>Log4cpp-devel mailing list
>>Log...@li...
>>https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>>    
>>
>
>
>
>  
>

[Log4cpp-devel] Can't link tests with Sun Workshop 6.2 and log4cpp 0.2.7

[Russell, M. <Mar...@cs...>]

When attempting to build all of log4cpp it gets to testmain and then the
linker has problems linking, spitting out the following

ild: (undefined symbol) void
__rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::alloca
tor<char> >,std::pair<cons\
t std::basic_string<char,std::char_traits<char>,std::allocator<char>
>,log4cpp::Appender*>,__rwstd::__select1st<std::pair<const std\
::basic_string<char,std::char_traits<char>,std::allocator<char>
>,log4cpp::Appender*>,std::basic_string<char,std::char_traits<char>\
,std::allocator<char> >
>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<cha
r> > >,std::allocator<std::pair\
<const std::basic_string<char,std::char_traits<char>,std::allocator<char>
>,log4cpp::Appender*> > >::__deallocate_buffers() -- refe\
renced in ../src/.libs/liblog4cpp.so
ild: (undefined symbol)
__rwstd::__rb_tree<log4cpp::Appender*,std::pair<log4cpp::Appender*const,bool
>,__rwstd::__select1st<std::pai\
r<log4cpp::Appender*const,bool>,log4cpp::Appender*>,std::less<log4cpp::Appen
der*>,std::allocator<std::pair<log4cpp::Appender*const,\
bool> > >::iterator
__rwstd::__rb_tree<log4cpp::Appender*,std::pair<log4cpp::Appender*const,bool
>,__rwstd::__select1st<std::pair<lo\
g4cpp::Appender*const,bool>,log4cpp::Appender*>,std::less<log4cpp::Appender*
>,std::allocator<std::pair<log4cpp::Appender*const,bool\
> >
>::erase(__rwstd::__rb_tree<log4cpp::Appender*,std::pair<log4cpp::Appender*c
onst,bool>,__rwstd::__select1st<std::pair<log4cpp::\
Appender*const,bool>,log4cpp::Appender*>,std::less<log4cpp::Appender*>,std::
allocator<std::pair<log4cpp::Appender*const,bool> > >::\
iterator,__rwstd::__rb_tree<log4cpp::Appender*,std::pair<log4cpp::Appender*c
onst,bool>,__rwstd::__select1st<std::pair<log4cpp::Appe\
nder*const,bool>,log4cpp::Appender*>,std::less<log4cpp::Appender*>,std::allo
cator<std::pair<log4cpp::Appender*const,bool> > >::iter\
ator) -- referenced in ../src/.libs/liblog4cpp.so

There's more but you get the idea.  
I've tried adding -lCstd && -lC, as well as the real rogue wave library all
to no effect.  I figure that if I can't link the tests then the app that is
using log4cpp certainly ain't going to link. So any idea's for a solution?


Mark A Russell
CSG Systems, Inc.
E-Mail: Mark_Russell AT CSGSystems.com

[Log4cpp-devel] PatternLayout date formating merged, MSVC6 files updated in CVS

[David R. <dre...@mo...>]

Please see the ChangeLog for more details.

Regards,=20

David Resnick=20
MobileSpear Inc.=20

RE: [Log4cpp-devel] Warning: win32 dll can't export containerclasses

[David R. <dre...@mo...>]

U291bmRzIGdvb2QuIEknbGwgYmUgYWJsZSB0byBjaGVjayBpdCBuZXh0IHdlZWsuDQogDQpSZWdh
cmRzLA0KRGF2aWQNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEJhc3Rp
YWFuIEJha2tlciBbbWFpbHRvOmJhc3RpYWFuLmJha2tlckBsaWZlbGluZS5ubF0gDQoJU2VudDog
VHVlIDAyLUp1bC0wMiAyMjozOSANCglUbzogRGF2aWQgUmVzbmljayANCglDYzogbG9nNGNwcC1k
ZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJU3ViamVjdDogUkU6IFtMb2c0Y3BwLWRldmVs
XSBXYXJuaW5nOiB3aW4zMiBkbGwgY2FuJ3QgZXhwb3J0IGNvbnRhaW5lcmNsYXNzZXMNCgkNCgkN
Cg0KCUhpIERhdmlkLA0KCQ0KCUkndmUgY2hhbmdlZCBnZXRBbGxBcHBlbmRlcnMoKSB0byByZXR1
cm4gYSBzdGQ6OnZlY3RvciwgY291bGQgeW91IGNoZWNrDQoJd2hldGhlciB0aGlzIHNvbHZlcyB0
aGUgRExMIHByb2JsZW0uDQoJQW5kIHllcywgaXQgd291bGQgYmUgbmljZSB0byBrbm93IGlmIHRo
aXMgcmVzdHJpY3Rpb24gc3RpbGwgYXBwbGllcyB0bw0KCW5ld2VyIE1TVkMgdmVyc2lvbnMuIEkn
ZCByYXRoZXIgcmVjb21tZW5kIHBlb3BsZSB0byB1cGdyYWRlIHRoYW4gdG8gaGF2ZQ0KCWRpZmZl
cmVudCBBUElzIGZvciBETEwgdnMgbm9uLURMTCBidWlsZHMuDQoJDQoJUmVnYXJkcywNCgkNCglC
YXN0aWFhbg0KCQ0KCQ0KCU9uIFRodSwgMjAwMi0wNi0yNyBhdCAwOTowMSwgRGF2aWQgUmVzbmlj
ayB3cm90ZToNCgk+IFllYWgsIGl0IHN1Y2tzIHByZXR0eSBiYWQuIEkgZG9uJ3Qga25vdyBpZiBp
dCBpcyBzdGlsbCB0cnVlIHdpdGggdGhlDQoJPiBsYXRlc3QgdmVyc2lvbiBvZiBNU1ZDIChNU1ZD
Lk5FVD8gTVNWQzc/KS4NCgk+DQoJPiBUaGUgcHJvYmxlbSBhbHNvIGFwcGxpZXMgdG8gQ2F0ZWdv
cnk6OmdldEFsbEFwcGVuZGVycygpLg0KCT4NCgk+IEknbSBub3Qgc3VyZSB0aGF0IHRoZSBwcm9i
bGVtIGlzIHNvIHNpZ25pZmljYW50LiBJdCBpcyBvbmx5IHJlbGV2YW50IHRvDQoJPiB0aGUgd2lu
MzIgZGxsIGJ1aWxkOiBtYXliZSB0aGUgcHJvYmxlbSBtZXRob2RzIGNhbiBiZSBtYWRlIHByaXZh
dGUgZm9yDQoJPiB0aGF0IGJ1aWxkPyBPciBqdXN0IHB1dCB3YXJuaW5ncyBpbiB0aGUgZG9jdW1l
bnRhdGlvbj8NCgk+DQoJPiBZb3VyIHNvbHV0aW9uIHRvIGNoYW5nZSB0aGUgY29udGFpbmVyIHJl
dHVybmVkIHRvIHN0ZDo6dmVjdG9yIHdvdWxkIGJlDQoJPiBuaWNlIHRob3VnaC4uLiBBdCBsZWFz
dCB3aXRoIGdldEFsbEFwcGVuZGVycygpIGl0IHdvdWxkbid0IGJyZWFrIGFueQ0KCT4gcHJvZHVj
dGlvbiByZWxlYXNlIEFQSXMuDQoJPg0KCT4gUmVnYXJkcywNCgk+DQoJPiBEYXZpZCBSZXNuaWNr
DQoJPiBNb2JpbGVTcGVhciBJbmMuDQoJPiANCgk+DQoJPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KCT4gRnJvbTogQmFzdGlhYW4gQmFra2VyIFttYWlsdG86QmFzdGlhYW4uQmFra2VyQGxp
ZmVsaW5lLm5sXQ0KCT4gU2VudDogVHVlc2RheSwgSnVuZSAyNSwgMjAwMiAxMDozNQ0KCT4gVG86
IERhdmlkIFJlc25pY2sNCgk+IENjOiBsb2c0Y3BwLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5l
dA0KCT4gU3ViamVjdDogUmU6IFtMb2c0Y3BwLWRldmVsXSBXYXJuaW5nOiB3aW4zMiBkbGwgY2Fu
J3QgZXhwb3J0DQoJPiBjb250YWluZXJjbGFzc2VzDQoJPg0KCT4NCgk+IEhtbSwgdGhhdCBzdWNr
cy4gQW55IGNoYW5jZSBvZiBNUyBmaXhpbmcgdGhpcyBwcm9ibGVtIHNvb24/IEJlaW5nDQoJPiBs
aW1pdGVkIHRvIG9ubHkgdXNlIHN0ZDo6dmVjdG9yIGluIHlvdXIgQVBJcyBpcyByaWRpY3Vsb3Vz
LiBIb3dldmVyDQoJPiBjdXJycmVudGx5IG9ubHkgZ2V0Q3VycmVudENhdGVnb3JpZXMoKSBpcyBh
ZmZlY3RlZC4gSXQgdXNlcyBzdGQ6OnNldA0KCT4gbm93LCBidXQgY2hhbmdpbmcgdGhhdCB0byBz
dGQ6OnZlY3RvciB3b3VsZG4ndCBodXJ0IHZlcnkgbXVjaCwNCgk+IGFuZCBtYXkgYmUgbW9yZSBl
ZmZpY2llbnQgYXMgc3RkOjp2ZWN0b3IgaXMgdGhlIHNpbXBsZXN0IGNvbnRhaW5lciBpbg0KCT4g
bW9zdCBTVEwgaW1wbGVtZW50YXRpb25zLiBZZXMsIGl0J3MgYW4gaW5jb21wYXRpYmxlIEFQSSBj
aGFuZ2UsIGJ1dA0KCT4gMC4zLnggaXMgYSBkZXZlbG9wbWVudCBicmFuY2ggYW55d2F5Lg0KCT4N
Cgk+IFJlZ2FyZHMsDQoJPg0KCT4gQmFzdGlhYW4NCgk+DQoJPiBQUy4gVGhlIGFib3ZlIGlzIG5v
dCBhIGNvbW1pdG1lbnQgdG8ga2VlcCB0aGUgbG9nNGNwcCBBUEkgTVNWQyBETEwNCgk+IGV4cG9y
dCBjbGVhbi4NCgk+DQoJPiAgDQoJPiBPbiBTdW4sIDIwMDItMDYtMjMgYXQgMTA6MDgsIERhdmlk
IFJlc25pY2sgd3JvdGU6DQoJPiA+IEkgZm91bmQgdGhpcyBvdXQgd2hlbiB0cnlpbmcgdG8gdXNl
IENhdGVnb3J5OjpnZXRDdXJyZW50Q2F0ZWdvcmllcygpLA0KCT4gPiB3aGljaCByZXR1cm5zIHN0
ZDo6c2V0PENhdGVnb3J5Kj4qLiBUaGUgc2V0IEkgZ290IGhhZCAxIGdvb2QgcG9pbnRlcjsNCgk+
ID4gdGhlIHJlc3Qgd2VyZSBpbnZhbGlkLg0KCT4gPg0KCT4gPiBUaGUgcHJvYmxlbSBpcyBkZXRh
aWxlZCBieSBNUyBpbiBRMTY4OTU4ICJIT1dUTzogRXhwb3J0aW5nIFNUTA0KCT4gPiBDb21wb25l
bnRzIEluc2lkZSAmIE91dHNpZGUgb2YgYSBDbGFzcyIuIEhlcmUgaXMgdGhlIGtleSBwYXJhZ3Jh
cGg6DQoJPiA+DQoJPiA+ICJTb21lIFNUTCBjbGFzc2VzIGNvbnRhaW4gbmVzdGVkIGNsYXNzZXMu
IFRoZXNlIGNsYXNzZXMgY2FuIG5vdCBiZQ0KCT4gPiBleHBvcnRlZC4gRm9yIGluc3RhbmNlLCBk
ZXF1ZSBjb250YWlucyBhIG5lc3RlZCBjbGFzcyBkZXF1ZTo6aXRlcmF0b3IuDQoJPg0KCT4gPiBJ
ZiB5b3UgZXhwb3J0IGRlcXVlLCB5b3Ugd2lsbCBnZXQgYSB3YXJuaW5nIHRoYXQgeW91IG11c3Qg
ZXhwb3J0DQoJPiA+IGRlcXVlOjppdGVyYXRvci4gSWYgeW91IGV4cG9ydCBkZXF1ZTo6aXRlcmF0
b3IsIHlvdSBnZXQgYSB3YXJuaW5nIHRoYXQNCgk+DQoJPiA+IHlvdSBtdXN0IGV4cG9ydCBkZXF1
ZS4gVGhpcyBpcyBjYXVzZWQgYnkgYSBkZXNpZ25lZCBsaW1pdGF0aW9uIHRoYXQNCgk+ID4gb25j
ZSBhIHRlbXBsYXRlIGNsYXNzIGlzIGluc3RhbnRpYXRlZCwgaXQgY2FuIG5vdCBiZSByZS1pbnN0
YW50aWF0ZWQNCgk+ID4gYW5kIGV4cG9ydGVkLiBUaGUgb25seSBTVEwgY29udGFpbmVyIHRoYXQg
Y2FuIGN1cnJlbnRseSBiZSBleHBvcnRlZCBpcw0KCT4NCgk+ID4gdmVjdG9yLiBUaGUgb3RoZXIg
Y29udGFpbmVycyAodGhhdCBpcywgbWFwLCBzZXQsIHF1ZXVlLCBsaXN0LCBkZXF1ZSkNCgk+ID4g
YWxsIGNvbnRhaW4gbmVzdGVkIGNsYXNzZXMgYW5kIGNhbm5vdCBiZSBleHBvcnRlZC4iDQoJPiA+
DQoJPiA+IFNvIGlmIHlvdSB3YW50IHRvIHVzZSBtZXRob2RzIHN1Y2ggYXMNCgk+ID4gQ2F0ZWdv
cnk6OmdldEN1cnJlbnRDYXRlZ29yaWVzKCksIGRvIHRoZW0gaW4gYSBoZWxwZXIgY2xhc3MgdGhh
dCBpcw0KCT4gPiBsaW5rZWQgYXMgcGFydCBvZiB0aGUgRExMLiBJIGFkZGVkIHdoYXQgSSBuZWVk
ZWQgdG8gdGhlDQoJPiA+IFNpbXBsZUNvbmZpZ3VyYXRvciAod2hhdCBJIG5lZWRlZCB0byBkbyB3
YXMgZGVsZXRlIHByZXZpb3VzbHkgZGVmaW5lZA0KCT4gPiBhcHBlbmRlcnMgZnJvbSBhbGwgY2F0
ZWdvcmllcyBiZWZvcmUgcmVsb2FkaW5nIGEgY29uZmlnIGZpbGUsIHNvIGl0DQoJPiA+IG1hZGUg
c2Vuc2UgaW4gYW55IGNhc2UgdG8gcHV0IGl0IHRoZXJlLikNCgk+ID4NCgk+ID4gUmVnYXJkcywN
Cgk+ID4NCgk+ID4gRGF2aWQgUmVzbmljaw0KCT4gPiBNb2JpbGVTcGVhciBJbmMuDQoJPiA+DQoJ
PiA+DQoJPiA+DQoJPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCgk+ID4gU3BvbnNvcmVkIGJ5Og0KCT4gPiBUaGlua0dlZWsgYXQgaHR0
cDovL3d3dy5UaGlua0dlZWsuY29tLw0KCT4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KCT4gPiBMb2c0Y3BwLWRldmVsIG1haWxpbmcgbGlzdCBMb2c0
Y3BwLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCT4gPiBodHRwczovL2xpc3RzLnNvdXJj
ZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9sb2c0Y3BwLWRldmVsDQoJPg0KCT4NCgk+DQoJDQoJ
DQoJDQoNCg==

RE: [Log4cpp-devel] Warning: win32 dll can't export containerclasses

[Bastiaan B. <bas...@li...>]

Hi David,

I've changed getAllAppenders() to return a std::vector, could you check
whether this solves the DLL problem.
And yes, it would be nice to know if this restriction still applies to
newer MSVC versions. I'd rather recommend people to upgrade than to have
different APIs for DLL vs non-DLL builds. 

Regards,

Bastiaan
 

On Thu, 2002-06-27 at 09:01, David Resnick wrote:
> Yeah, it sucks pretty bad. I don't know if it is still true with the
> latest version of MSVC (MSVC.NET? MSVC7?). 
> 
> The problem also applies to Category::getAllAppenders().
> 
> I'm not sure that the problem is so significant. It is only relevant to
> the win32 dll build: maybe the problem methods can be made private for
> that build? Or just put warnings in the documentation?
> 
> Your solution to change the container returned to std::vector would be
> nice though... At least with getAllAppenders() it wouldn't break any
> production release APIs.
> 
> Regards,
> 
> David Resnick
> MobileSpear Inc.
>  
> 
> -----Original Message-----
> From: Bastiaan Bakker [mailto:Bas...@li...] 
> Sent: Tuesday, June 25, 2002 10:35
> To: David Resnick
> Cc: log...@li...
> Subject: Re: [Log4cpp-devel] Warning: win32 dll can't export
> containerclasses
> 
> 
> Hmm, that sucks. Any chance of MS fixing this problem soon? Being
> limited to only use std::vector in your APIs is ridiculous. However
> currrently only getCurrentCategories() is affected. It uses std::set
> now, but changing that to std::vector wouldn't hurt very much, 
> and may be more efficient as std::vector is the simplest container in
> most STL implementations. Yes, it's an incompatible API change, but
> 0.3.x is a development branch anyway. 
> 
> Regards,
> 
> Bastiaan
> 
> PS. The above is not a commitment to keep the log4cpp API MSVC DLL
> export clean.
> 
>   
> On Sun, 2002-06-23 at 10:08, David Resnick wrote:
> > I found this out when trying to use Category::getCurrentCategories(), 
> > which returns std::set<Category*>*. The set I got had 1 good pointer; 
> > the rest were invalid.
> > 
> > The problem is detailed by MS in Q168958 "HOWTO: Exporting STL 
> > Components Inside & Outside of a Class". Here is the key paragraph:
> > 
> > "Some STL classes contain nested classes. These classes can not be 
> > exported. For instance, deque contains a nested class deque::iterator.
> 
> > If you export deque, you will get a warning that you must export 
> > deque::iterator. If you export deque::iterator, you get a warning that
> 
> > you must export deque. This is caused by a designed limitation that 
> > once a template class is instantiated, it can not be re-instantiated 
> > and exported. The only STL container that can currently be exported is
> 
> > vector. The other containers (that is, map, set, queue, list, deque) 
> > all contain nested classes and cannot be exported."
> > 
> > So if you want to use methods such as 
> > Category::getCurrentCategories(), do them in a helper class that is 
> > linked as part of the DLL. I added what I needed to the 
> > SimpleConfigurator (what I needed to do was delete previously defined 
> > appenders from all categories before reloading a config file, so it 
> > made sense in any case to put it there.)
> > 
> > Regards,
> > 
> > David Resnick
> > MobileSpear Inc. 
> > 
> > 
> > 
> > -------------------------------------------------------
> > Sponsored by:
> > ThinkGeek at http://www.ThinkGeek.com/ 
> > _______________________________________________
> > Log4cpp-devel mailing list Log...@li...
> > https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
> 
> 
> 

RE: [Log4cpp-devel] Warning: win32 dll can't export containerclasses

[David R. <dre...@mo...>]

Yeah, it sucks pretty bad. I don't know if it is still true with the
latest version of MSVC (MSVC.NET? MSVC7?).=20

The problem also applies to Category::getAllAppenders().

I'm not sure that the problem is so significant. It is only relevant to
the win32 dll build: maybe the problem methods can be made private for
that build? Or just put warnings in the documentation?

Your solution to change the container returned to std::vector would be
nice though... At least with getAllAppenders() it wouldn't break any
production release APIs.

Regards,

David Resnick
MobileSpear Inc.
=20

-----Original Message-----
From: Bastiaan Bakker [mailto:Bas...@li...]=20
Sent: Tuesday, June 25, 2002 10:35
To: David Resnick
Cc: log...@li...
Subject: Re: [Log4cpp-devel] Warning: win32 dll can't export
containerclasses


Hmm, that sucks. Any chance of MS fixing this problem soon? Being
limited to only use std::vector in your APIs is ridiculous. However
currrently only getCurrentCategories() is affected. It uses std::set
now, but changing that to std::vector wouldn't hurt very much,=20
and may be more efficient as std::vector is the simplest container in
most STL implementations. Yes, it's an incompatible API change, but
0.3.x is a development branch anyway.=20

Regards,

Bastiaan

PS. The above is not a commitment to keep the log4cpp API MSVC DLL
export clean.

 =20
On Sun, 2002-06-23 at 10:08, David Resnick wrote:
> I found this out when trying to use Category::getCurrentCategories(),=20
> which returns std::set<Category*>*. The set I got had 1 good pointer;=20
> the rest were invalid.
>=20
> The problem is detailed by MS in Q168958 "HOWTO: Exporting STL=20
> Components Inside & Outside of a Class". Here is the key paragraph:
>=20
> "Some STL classes contain nested classes. These classes can not be=20
> exported. For instance, deque contains a nested class deque::iterator.

> If you export deque, you will get a warning that you must export=20
> deque::iterator. If you export deque::iterator, you get a warning that

> you must export deque. This is caused by a designed limitation that=20
> once a template class is instantiated, it can not be re-instantiated=20
> and exported. The only STL container that can currently be exported is

> vector. The other containers (that is, map, set, queue, list, deque)=20
> all contain nested classes and cannot be exported."
>=20
> So if you want to use methods such as=20
> Category::getCurrentCategories(), do them in a helper class that is=20
> linked as part of the DLL. I added what I needed to the=20
> SimpleConfigurator (what I needed to do was delete previously defined=20
> appenders from all categories before reloading a config file, so it=20
> made sense in any case to put it there.)
>=20
> Regards,
>=20
> David Resnick
> MobileSpear Inc.=20
>=20
>=20
>=20
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/=20
> _______________________________________________
> Log4cpp-devel mailing list Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

Re: [Log4cpp-devel] Warning: win32 dll can't export container classes

[Bastiaan B. <Bas...@li...>]

Hmm, that sucks. Any chance of MS fixing this problem soon? Being
limited to only use std::vector in your APIs is ridiculous.
However currrently only getCurrentCategories() is affected. It uses
std::set now, but changing that to std::vector wouldn't hurt very much, 
and may be more efficient as std::vector is the simplest container in
most STL implementations.
Yes, it's an incompatible API change, but 0.3.x is a development branch
anyway. 

Regards,

Bastiaan

PS. The above is not a commitment to keep the log4cpp API MSVC DLL
export clean.

  
On Sun, 2002-06-23 at 10:08, David Resnick wrote:
> I found this out when trying to use Category::getCurrentCategories(),
> which returns std::set<Category*>*. The set I got had 1 good pointer;
> the rest were invalid.
> 
> The problem is detailed by MS in Q168958 "HOWTO: Exporting STL
> Components Inside & Outside of a Class". Here is the key paragraph: 
> 
> "Some STL classes contain nested classes. These classes can not be
> exported. For instance, deque contains a nested class deque::iterator.
> If you export deque, you will get a warning that you must export
> deque::iterator. If you export deque::iterator, you get a warning that
> you must export deque. This is caused by a designed limitation that once
> a template class is instantiated, it can not be re-instantiated and
> exported. The only STL container that can currently be exported is
> vector. The other containers (that is, map, set, queue, list, deque) all
> contain nested classes and cannot be exported."
> 
> So if you want to use methods such as Category::getCurrentCategories(),
> do them in a helper class that is linked as part of the DLL. I added
> what I needed to the SimpleConfigurator (what I needed to do was delete
> previously defined appenders from all categories before reloading a
> config file, so it made sense in any case to put it there.)
> 
> Regards, 
> 
> David Resnick 
> MobileSpear Inc. 
> 
> 
> 
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] Patch: date formatting for PatternLayout

[David R. <dre...@mo...>]

This patch adds date formatting for the PatternLayout. See
include/log4cpp/PatternLayout.hh for usage details.

There are changes to tests/testPattern.cpp and the addition of
/msvc6/testPattern/testPattern.dsp as well.

The patch was also submitted to the sourceforge site.

Regards,=20

David Resnick=20
MobileSpear Inc.=20