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