Boost Users :
From: Boris (boriss_at_[hidden])
Date: 2008-06-09 07:11:29
On Mon, 09 Jun 2008 11:11:31 +0200, Mojmir Svoboda
> [...]this 'going public' thingy is not really 'i do want write logging
> library right here right now' but more like 'heey, i have this in my
> drawer and i can make it better than the first version, but does
> anybody want it?' because i can surely find myself another toy elsewhere.
While I'm not making the final decision which library is going to be the
Boost logging library it might make more sense then to discuss what you
think would make your library better than the first version? If the ideas
are then implemented in John's or your library is secondary? As John's
libary is not finished anyway and as I for example also like some things
to be changed new ideas are surely appreciated.
> [...]this is not my priority right now. now i am working with something
> called buffer manager and something called sink. buffer manager gives me
> space to write (if any.. of course message will be dropped if there is
> not) and sink takes ownership of full buffer and does something very
> blackboxish then: there could be a stdout, stderr, socket with low
> priority thread, small black hole or a hidden schrodinger's cat
> reading and not reading the messages at the same time ;)
John's library has a concept called destination which sounds like your
sink. There is another concept called formatter which, well, formats
messages before they are written to the destination. I'm not sure if there
is any buffer involved (there is a cache though which can be activated and
deactivated at any time if I'm not wrong).
In my opinion one of the most important questions is what else can a Boost
logging library offer than what we can do today with:
clog << "Logging ...";
As we can easily redirect clog or replace it with another stream object
where we can control the buffer there must be some added value?
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net