Boost logo

Boost :

From: Jamie Allsop (ja11sop_at_[hidden])
Date: 2008-01-08 19:30:19

John Torjo wrote:
> Boost Logging v2 - new version (v0.13.6)

[list of features snipped]

> All in all, I've added quite a few features - so, take a look! Look
> forward to your feedback!


I've just started looking at this new version of your logging library. I
have used a modified version of your earlier review candidate for some
time now in a production system and all in all it's been quite good.

However in both that version and this newer version I see (at least for
me) a very important use case overlooked. Simply I would like to be able
to use logging in library code.

For example, imagine I have a header based library that is somewhat
complex and therefore I would like to embed logging statements in the
library for possible future exposure in a production system.

I'd want to be able to write something like this (using a syntax similar
to that from your fist library).

#include <other_stuff>

#include <boost/logging.hpp>

BOOST_DEFINE_LOG(persitence_synchroniser, "persitence.synchroniser")

namespace persistence {

template< class PersistableContainer, class DatabaseInstance >
class synchroniser : private boost::noncopyable


template< class PersistableContainer, class DatabaseInstance >
void synchroniser< PersistableContainer, DatabaseInstance >::
             << BOOST_LOG_FILE_AND_LINE
             << "synchroniser::run() - Started"
             << std::endl;





Note that the idea here would be to use a naming strategy for the log
that would minimise clashes.

A couple of points then,

1. Writing BOOST_DEFINE_LOG() or something like that is all that is
required to make the log available for writing to (no separate declare
and define).

2. I would hope that if the log was never enabled by a client of the
library, the BOOST_LOG() calls would be optimised away. I recall there
being some discussion about this during the last review but I don't have
a reference to hand.

If this is possible then the logging library would be capable of
providing a generally useful logging facility which could be used in
library code also (with a single dependency on the boost logging library
but I do not see that as a bad thing if logging could be generally useful).

Incidentally this is how we used a modified version of your original log
library submission. It allowed us to get log statements into the parts
of our libraries where they were needed most and when necessary we
switched them on.

I hope what I describe makes sense.


> Best,
> John

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