Stack OverflowBest logging framework for native C++?
[+103] [15] Jox
[2009-03-30 07:45:27]
[ c++ logging ]

I'm looking for logging framework for C++ project. My best shot was log4cxx, but it seems that it's abandoned project, with development stopped ~4 years ago, with only one update in last 4-5 years.

Anything better that log4cxx? (log4c & log4cpp are also totally out-of-date)...

[+45] [2009-03-30 08:47:22] Klaim

Update : Boost.Log has been accepted in Boost [1] under conditions and will be available in a coming release. The current target release would be in the end of 2012.

Update 2: Good informations on Boost.Log can be found in these questions:

Another logging library, Boost.Log [4] (by Andrey Semashev, not Boost.Logging by John Torjo) has been proposed to boost and is currently a work in progress.

From the mailing list :

The archive with the library source code, tests and docs is available in the Vault:

The online docs are also available on the SourceForge page:

The latest code snapshot can be downloaded from CVS on the SourceForge project page:

The code should be compatible with Boost 1.38. Might also work with 1.37, but I didn't try.


Currently it's not building with the intel compiler under linux… - bua
Well,it's a work in progress I guess. - Klaim
I used this for a project, and was quite pleased with how well it worked, although at times the verbosity was somewhat discouraging. Thankfully there are helper macros and free functions to simplify things, though. - adzm
Yeah and as it was reviewed and the verbisity and necessary macros/shortcuts pointed, the boost-release version should be much better. I just hope it don't kill performance, as I'm working with games... - Klaim
(4) Apparently this library is NOT in boost. It has been withdrawn by the author. - Sardathrion
(6) The one I'm pointing is not Boost::Logging by John Torjo ( that indeed have been refused and later abandonned by his author (aparently), but Boost::Log by Andrey Semashev that have been accepted in boost but with conditions ( and that, from last news, is targeted at the 1.47.0 release (in few months). - Klaim
if looking to waste 3-4 hours with unsuccessful build, by all means use this library. Otherwise wait till it gets to the boost tree. - C-x C-t
Errata: Boost.Log will not be in 1.47.0 , but in a later release. - Klaim
(1) With boost.log you can really make very custom logging, but requires some time to spend on reading documentation and examining examples. Problems with build were recently least some of them. But still you sould build boost, (which takes several hours to compile). Use version from svn trunk - Yuriy Petrovskiy
[+42] [2010-02-24 16:16:28] m_pGladiator

I'm looking also for the same thing. So far I evaluated:

  • log4cplus [1] - nice API, easy build, but memory leaks. The author does not care about the memory leaks and they will not be fixed I guess (see here [2])
  • log4cpp [3] - nice API, easy build, but memory leaks
  • log4cxx [4] - requires a bunch of apache stuff to get build (really annoyng until you build it) and at the end it has memory leaks... It is also very big
  • glog [5] - so far version 0.3.0 - too early. Looks promesing though, but maybe later. It still has memory leaks, but it is small
  • ezlogger [6] - cool nice small logging library. The only one without memory leaks! Unfortunately there are no features like configuration files, rolling logs e.t.c. Just logging, but works. It consists of several HPP files, so you just include them in your project. No need to build the whole world in order to work (Apache should learn from that!). The code looks nice, it has superb documentation, so anybody can extend it with whatever features in no time

I still want to look at Boost [7] and the Pantheios [8], but I think ezlogger will be the tool of choice for me. Did I miss some library here? I'd like to make a complete list if possible.


(12) It should be pointed out that those memory "leaks" for log4cplus are leaks in name, but not practice. - Steve
(11) I consider a memory leak everything that allocates memory and not release it. Calling the operator new in a constructor and having empty corresponding destructor is a memory leak. The fact that the object is instantiated only once (so it leaks once and it is not growing) does not fix the leak. - m_pGladiator
(2) Just watch if you use ezlogger's FUNCTRACKER stuff, it is not multithread safe because of the static my_stack member in ezlogger_output_policy::get_stack. Other macros should be safe or at least they don't use that member. I just got rid of it, you will loose the DISPLAYSTACK functions but if you don't need it it should work. - n1ckp
(1) Thanks n1ck! I actually have to post an update. Later the Pantheios shown the best performance and it was easy to write a custom backend for using it - m_pGladiator
(9) I would agree with @Steve - the allocations you're talking about don't come under the heading 'memory leaks', unless 'memory leak' is defined in a way that misses the point somewhat. In a similar way, the CRT will allocate stuff that you cannot deallocate without exiting the process. Those allocations aren't really memory leaks either. The allocations shouldn't be a 'show-stopper' issue when it comes to deciding whether or not to use the library. - mackenir
(BTW, I'm specifically talking about the allocations in log4cplus). - mackenir
[+19] [2009-03-30 11:42:39] Serge

You can take a look at this article [1], it discribes a simple, typesafe, threadsafe, portable logging mechanism.


(1) +1 I implemented a logging system based on this article and was really happy with it. It's intuitive, flexible, low overhead and easy to use. - markh44
Just tried to follow that link and get a blank page. Found another link at…. Is that the same article? - jschoen
@jschoen Yes, it's the same link. - Serge
Any chance to get the zip file to the source code ? the download link on that page is broken ! - ZeroCool
[+17] [2009-03-30 17:49:29] Cwan [ACCEPTED]

Checkout Pantheios [1]. Haven't tried this myself, but have the greatest respect for Matthew Wilson.


Pantheios still does not support unicode from what I can tell. Just spent some time evaluating it only to discover I can't use it due to this issue. - Avalanchis
The 4th April 2010 release claims full widestring compatibility - dcw
(2) @Avalanchis: Out of curiosity, under what circumstances do you need Unicode logging support? - Joseph Garvin
(24) @Joseph You are developing in non english language and want native error output? Most of this world is non native english speaking. - RedX
Because of all the positive feedback on Pantheios, I was thrilled to try it. Sadly, it has no support for CMake and additionally it suffers from small bugs - like that the path to STLsoft may not contain whitespace when building on windows. - ThE_-_BliZZarD
[+11] [2009-03-30 07:54:25] Thomas Watnedal

The Boost Logging [1] framework seem pretty good. I've used it myself on a "toy project" but I haven't really tried it in a large application.

It was however rejected [2] for inclusion in the official Boost library [3], by the author himself. Thats not because its not a good library, it just didn't fit into the Boost library in its current form.


[+11] [2009-03-30 11:59:35] yesraaj

Here is a log library from google glog [1]


[+7] [2011-09-10 22:55:09] johnwbyrd

You may wish to consider the logog library. The documentation can be accessed here:

logog has basic multibyte character support, a no-memory-leak policy, a BSD-style license, runs on Windows and POSIX like systems, it's safe in a multithreaded environment, has very complete documentation, supports Unicode output, and maintains a test framework. Additionally, there are no external dependencies in logog beyond that which most modern compilers already provide -- it doesn't need Boost or STLSoft, for example.

This looks like a little gem. Looking forward to giving it a try. - alexr
Boost.Log seems heavy weight. I like logog. - SunLiWei
[+6] [2009-03-30 07:51:06] Bill Summers

Have a look at the logging library which has been proposed for the Boost C++ libraries.


[+6] [2009-03-31 13:45:27] fco.javier.sanz

I don't think that log4ccxx is abandoned at all. I am actually using the last release of log4cxx in my current project and it works pretty well. Yo can check it here [1]


(1) that link just confirms my state: "only one update in last 4-5 years" - Jox
(3) I think it has just reached a level of stability - there really isn't anything more to add. - Martin Beckett
(2) I think log4cxx tries to follow the lo4java design. Log4java has a 1.3 branch abandoned and another branch 2.0 that is still experimental. Version 1.2 of log4java has been there for while so I guess that without new versions of log4java there won't be new log4cxx - fco.javier.sanz
[+6] [2009-06-10 23:20:14] lenkite

Pantheios is great, but no unicode/wchar_t support. Ditto for google-glog. One advantage of google-glog is that if you use gflags for options parsing, it builds upon it so that debug flags are automatically available for your program. But no wchar_t support is bad.

log4cxx requires apache portable runtime.

log4cplus is kinda primitive.

Boost.Log by Andrey Semashev really looks good. I am going to try it out and see how it goes.

I am just hoping that I don't have to end up rolling my own..

Any updates on how Boost.Log worked for you? - Avalanchis
April 2010 release claims full widestring compatibility. - dcw
[+6] [2010-05-14 08:48:13] wilx

log4cplus - nice API, easy build, but memory leaks. The author does not care about the memory leaks and they will not be fixed I guess (see here)

What you consider leaks are not leaks. The memory gets destroyed and freed properly, as far as I know, at static variables destruction time. IMHO your leak detector is showing false positives here. If your leak detector has any sort for textual output, please share it, attach it to the bug report.

[+1] [2009-03-30 08:00:22] jpoh

I've used NLog [1] in our native C++ projects. Its primarily a .NET logging framework but it does offer a COM interop out of the box (which admittedly doesn't offer full functionality but the source code is available so you can grab the source and roll your own COM interop exposing the functionality that you need).


the N in NLog is for .Net, not for Native, although it can be used by C++, it still requires .NET at runtime - 赵如飞
[+1] [2009-05-13 22:27:59] John K

I don't see why few updates to log4cxx are a bad thing, necessarily. It's working great in my project.

(1) Of course it's not necessarily a bad thing. Thing is we want to use out-of-the box tested logging framework, and log4cxx doesn't even compile in VS2k8 easily. - Jox
(2) Ditto here-- it'd be pretty suite if log4cxx build on many newer compilers without requiring goofy, smack-yourself-in-the-forehead patches. - Rhys Ulerich
(3) As well it can segfault in multithreaded apps ( This problem has been on the books for a year, with no fix. - rbellamy
[+1] [2011-08-12 15:54:23] Omnifarious

Nobody has yet mentioned rlog [1]. I'm not sure how thread safe it is. And there is a lot of ugly macro hackery. But it is very fast to have a logging point that is disabled, and it is pretty flexible in choosing what gets logged at runtime.


rlog looks quite interesting. Have you succeeded in logging to a file with it? - Burkhard
@Burkhard: I have. But after looking at rlog and trying it out, I've become disenchanted with it. Unfortunately, I can't remember why. :-/ - Omnifarious
[+1] [2011-08-19 11:52:09] dimitri

I've been using log4cplus [1] for some time. Portable and stable.