Boost logo

Boost :

From: Francis ANDRE (francis.andre_at_[hidden])
Date: 2004-10-22 10:01:11

I have asked to the owner of log4cpp if he would be interested in putting
log4cpp in the boost foundry (sandbox first for sure) with a change from the
LGPL licence to the boost one.

log4cpp is already packaged (somewhat) for multithreading. I think there
should be a small effort to change its internal threading structure to the
boost one and log4cpp has no strong adherence to any back iostream.
Moreover, the documentation is already in place.

In any case, I am volunter for spending some days of put boost::log4cpp in
the boost foundry as a starting point, but I do not want to reinvent the
wheel by starting a new package.

 IMHO, log4cpp is enough for now in term of functionalities. I am not saying
to not add functionnalities later on, but just make log4cpp as it is today
running well on boost first and then think about new functionnalities to

I am already overloaded (and I think most of us also) thus keeping the focus
on a utlity tool that is already a mature software is a good tradeoff
between the need/buy/build options


A good friend will come bail you out of jail..........
but, a true friend....will be sitting next to you saying:
 "...that was fun."
"Rene Rivera" <grafik.list_at_[hidden]> a écrit dans le message de
> Caleb Epstein wrote:
> > Anyone interested in working on such a beast?
> There's been interest and discussion in the past. Search the archives
> and you should find some discussion and if I remember correctly some
> previous work on the subject.
> >It should be reasonably
> > simple to write something with the new Boost.Iostreams facilities that
> > have been reviewed recently.  The must-have features for me are:
> >
> > * Uses iostreams
> I disagree. Like most things STL it should be independent of a stream
> back end. And ideally independent of a formatting front end. It should
> only be a tagging, filtering, and multiplexing interface.
> > * Thread-safe (e.g. two threads can't have their output intermixed in
> > the output file/stream/whatever like they would with simple ostream<<
> > operators)
> Yes, but only if needed. It might not be appropriate depending on the
> front end or back end. For example you might be dumping the "output" to
> a database which would create individual debug records. No need for
> thread safety at the log level in that case.
> > * Multiple possible output media (files, sockets, syslog, Windows
> > event log, etc)
> Multiplexing.
> > * Multiple named channels each with configurable "threshold" (e.g.
> > error, warning, debug, etc)
> And configurable, so that you can program what each one does on both the
> front end and to which back end they go to.
> > * Messages which won't be logged shouldn't even go through the
> > formatting step.  I'm pretty sure this cannot be done in a single call
> > w/o macros though.  For example:
> >
> >     BOOST_LOG (boost::log::debug, "This is a debug message: " <<
> > some_expensive_to_stream_class);
> >
> > Which would expand to something like:
> >
> >     if (boost::log::is_enabled_for (boost::log::debug)) {
> >         ostringstream __os; os << "This is a debug message: " <<
> > some_expensive_to_stream_class;
> >         boost::log::force_write (boost::log::debug, os.str ());
> >     }
> It's possible without macros for some compilers using careful template
> instaciations.
> For example the very simple logger I wrote uses syntax like so (and yes
> I prefer printf formatting :-)...
> log<RevisionLog>::trace(
> "RevisionControl::commit_; wait for ticket #%d",ticket);
> Because the formatting is done by the trace call, and the trace call is
> empty (and inlined) when the log is disabled, no formatting takes place.
> Something similar can be done regardless of what the formatting object
> is by having a specialization that does nothing.
> -- 
> -- Grafik - Don't Assume Anything
> -- Redshift Software, Inc. -
> -- rrivera/ - grafik/ - 102708583/icq
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at