I think you would need to explain the advantages of your (future) library over existing logging libraries. In what circumstances would your library be the better choice?
----- Original Message ----
From: Mojmir Svoboda <firstname.lastname@example.org>
Sent: Wednesday, June 4, 2008 5:07:14 PM
Subject: [Boost-users] yet another logging library
i'm trying to create a logging library framework. It is my second
attempt, the first can be seen at http://www.codeplex.com/flog
There is some documentation in the doc directory that is perhaps
The first version used boost::iostreams and not very smart locking
mechanism in mt environment (in terms of performance mainly), but served
more as a verification 'it can be done and it is not that ugly as i
thought' than a real library candidate. Now i'd like to focus on
performance and code size, so I made a sketch of the next version. It is
really small and is rather a model than anything usable, but before I
start implementation, I'd like to know opinion of library writers and
users - what do you think about the concept? is it worth continuing, or
i'd better go doing something better? :)
The sketch of the next version can be
seen at http://www.codeplex.com/fflog
It's meant to be illustration of the interface and it's usage itself.
Short summary of the design:
User specifies compile-time vector of requested filters that apply
to the logged text. Each filter requiring user's input is tagged and
when logging function is invoked, the supplied types are checked
against expected type, set to filter and later written to a buffer.
Buffers are managed by the sink_manager and likely is one of few
places that has to be mt-safe, as the rest is on the stack. I
thought about some lock-free queues of buffers that are assigned
to caller and filled returned back to write. The actual write
of the buffer
can be performed in dedicated lower-priority thread.
Run-time filtering like level or context is possible, but not
implemented yet. The main idea can be seen in the 1st version in
runtime_filtering.hpp. Again, runtime values are shared among
threads, so they have to be protected in mt environment.
Many thanks for your attention,
Boost-users mailing listBoostemail@example.com://lists.boost.org/mailman/listinfo.cgi/boost-users