Re: [Boost-users] yet another logging library

From: John Torjo (john.groups_at_[hidden])
Date: 2008-06-12 05:02:53

Mojmir Svoboda wrote:
> hello, John :)
>
>   
>> At this time, my library already does this - you can certainly specify 
>>     
>
> going quickly through your code i definitly must admit you are farer
> than i am. there's no apparent reason start new thingy. for example i'd
> probably never mess with internationalization ;)
>
>   
It's your call ;)
I think I've done about 6 other versions until I got to this one - which 
I will change as well ;)
>> whether you want thread-safety or not, and the lib is certainly efficient.
>>     
>
> can you give me some hints in the right direction, please? i mean
> some general advices "use this if you want be small, this if you want
> be fast, avoid that at all costs etc". i'd like both, of course.
>   
Well, this is quite hard:
- the locking strategy - make it a policy, which you can change later; 
this will also make it easy for you to test, using a single threaded app
- why do you apply filters to the logged text? A filter should be 
something able to say "yes" or "no" without looking at the text.
  First of all, if the filter says "no", you shouldn't need to do any 
processing of the text.
- I believe having a compile time vector for formatting the output is a 
mistake:
    typedef vector<time, sep, rt_level, sep, file, sep, line<>, sep, fn, 
sep, msg>::type pipe_mania;
   The user should be able to specify that at runtime - what if he wants 
to configure the log at runtime?

Other than that, I need to see more docs about what you're going to 
implement.

> i started with your sample and got it down to 12kB (assume 5k is C
> helloworld). that's not quite bad, i suppose, but still twice
> as it should be ;-P
>
>   
Oh well, I don't care that much about size nowadays.
> there are still 9 allocation - there is some vector at initialization
> time, but i'd have to read the sources more carefully. perhaps
> you could point out these places where expensive and other interesting
> things pop up.
>
> minor issues i found:
>  - logger.hpp:248 when cache is off, source cannot be compiled 
> 	(missing ifdef probably)
>   
Ouch. My bad - anyway, the caching will be gone in v3 of the lib ;)
>  - pthreads are detected incorrecty. even in singlethr model mutex
>     is required.
>   
What do you mean?
>  - it would be nice if it can compile with -fno-rtti -fno-exceptions
>     (op_equal and shared_ptr) see *)
>
>     *) note that it would be nice that all boost code that does not really 
>        need rtti could switch it off
>
>   
Yes I agree - I want to add this in the future ;)

Best,
John

-- 
http://John.Torjo.com -- C++ expert
http://blog.torjo.com
... call me only if you want things done right