From: JD (jean.daniel.michaud_at_[hidden])
Date: 2007-04-01 06:08:00
Jody Hagins wrote:
> I'd avise both of you to look at John Torjo's library, and read the
> review comments. John pulled the library, but it would benefit you
> greatly to see what others thought, and more specifically what they want
> in a boost logging library.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thanks Jody, we should definitely avoid starting from scratch again. The
problem is that there is so many divergent propositions and ideas, and
aggregate them won't be an easy task.
Here is a couple of ideas I have glanced from previous threads:
John Torjo had actually a similar point of view to mine. He was looking
for simplicity. As we are talking to a wide range of users, the library
should have almost no learning curve. Looking at the basic example in
the tutorial should be enough to get the fundamental usage of it.
John had also in mind the possibility to disconnect module of
application from the logger. For example, from a certain point in the
code, the GUI logs would be discarded. He also wanted the library to be
small, and I fully agree with this. A header file and that's it.
Not anyone agree with this, Vladimir Prus for example was expecting
something more configurable. Pavel Vozenilek added: "Maybe it is
possible to design a library which has (by default) this simple
interface but allows very fine customization." That is why I'm trying to
concentrate on the first part (design a library which has (by default)
this simple interface) and then, a second part could be handled by other
people interested in fine customization.
As a first set of requirements, Caleb Epstein stated those, and Rene
<CE>: Uses iostreams
<RR>: 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.
<CE>: Thread-safe (e.g. two threads can't have their output intermixed
in the output file/stream/whatever like they would with simple ostream<<
<RR>: 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.
<CE>: Multiple possible output media (files, sockets, syslog, Windows
event log, etc)
<CE>: Multiple named channels each with configurable "threshold" (e.g.
error, warning, debug, etc)
<RR>: And configurable, so that you can program what each one does on
both the front end and to which back end they go to.
<JD>: The log level (unsigned short) could handle that. OR maybe a mask
would be more appropriate ?
<CE>: 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.
Johan Nilson also engaged a lengthy discussion. Few ideas I have retain
Structured logging functionality. (<JD>: Is it formatting you are
log_item for formatting (<JD>: What I called log_element in the
library I have posted).
Daryl Green seems to have a put a lot of though into this and also
define a set of requirements I'm trying to summarize here, some of them
are pure citation:
- The logging library must be very efficient in handling disabled "logs".
- The logging library must be user extensible to add new output
(appender) facilities. This should be very easy and not require in-depth
knowledge/study of library/its docs to do. Appenders, which are likely
to have system dependencies, should not be tightly coupled with the core
logging facilities. (<JD>: Wishful thinking ?)
- The library must scale well. This should include the ability to
(efficiently) use a very minimal form of the library in small, perhaps
single-threaded only, apps as well as achieving good performance on
multiprocessor platforms in multi threaded apps. (<JD>: The first part I
was talking about, but the multi threading shall not be an option for me).
I agree also with Daryl that a very simple, extensible library can be
submitted first and extended in the future. If we wait for a complete
logging library to introduce it into boost, we'll never have it...
Maxim Yegorushkin asked for file management (cycling through log file,
file size control). I think this is interesting but shall not make it
into the core library. Maybe an helper object, in a distinct header file
could make it. Still I think this shall not be part of the first line of
proposal as it tends to divert the discussion and prevent decision on
the core logging library itself to be taken.
Some few ideas I saw:
+ Scoped log (<JD>: what is a scoped log?)
+ fast compile time
+ thread id: How to retrieve thread id with Boost.Threads?
+ program name: Is argv a good idea to retrieve program name? I don't
why i wouldn't, but just in case.
Now, some point raised during the formal review of John's library:
- Roman Yakovenko:
He was not pleased by the way John's library handles macro. In this
library, here is the way you log something:
BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl;
In any case, logging avtivated or not, the message will be streamed.
What I developped in the logging library posted above is to encapsulate
the streaming in the macro, as propose by many people during the discussion:
BOOST_LOG(1, "this is a debug message, i=" << i << std::endl);
The streaming will be performed only if necessary. Note, the library I
posted does not handle it correctly (the test is perform after the
streaming ;p), but it will.
I also see the need of a compile time disabling. Here again, I'm not
sure the library shall deal with this. Just define some macro like:
BOOST_LOG_L1(trace) BOOST_LOG(1, trace)
BOOST_LOG_L2(trace) BOOST_LOG(2, trace)
BOOST_LOG_L3(trace) BOOST_LOG(3, trace)
#endif // _DEBUG
- Andras Erdei:
"My main concern about logging is that it changes application
behavior: often there are bugs that only surface in release code
because logging is slow and it introduces synchronizing, so logging
should be as fast as possible, and locks should be avoided whenever
So another requirement would be that the library shall be as fast as
possible (pretty obvious) and the less intrusive as possible. But I'm
afraid the caveats described by Andras are inevitable.
"I do not want to declare and define and initialize logs, just
include a header, and then write "LOG << ..."; i do not want
to give names to logfiles, and i don't want runtime configurable
logs and log levels and multiline log entries and calling functions
that log from inside "LOG << ..." statements"
Well, I think the initialization part is essential, or you have a
library that is deciding things for you, and I don't think it's a good
" and i do not want to
pay (with runtime and additional typing) for the features i do not
Seems fair. -> Library shall stay simple. The more simple it is, the
more it has chance to get into boost and then be developed to something
more evolved. To Andras remarks, John answered:
" I made the logging library flexible (or at least I hope so :)), so
users can tweak the lib to their needs.Logging can be so much more that
writing to one file."
I think this is where troubles starts. As I said, the logging library
shall be simple to the cost of not being configurable at first. After
inclusion to boost, it can get better. Yes, it looks like petty
politics, but how come there is no logging library into boost with all
the interest it has in the past then ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk