----- Original Message ----
From: Mojmir Svoboda <mojmir.svoboda@illusionsoftworks.com>
To: boost-users@lists.boost.org
Sent: Wednesday, June 4, 2008 5:07:14 PM
Subject: [Boost-users] yet another logging library

Hello,

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
worth reading.

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,
Mojmir
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users