hello John, * John Torjo <john.groups@torjo.com> [2008-06-12 12:02:53 +0300]:
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
that is necessary nowadays. i still had no time to do my homework and explore mt in your code... i will until end of the week.
- 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.
if you are talking about my approach of filters, i mixed three concepts according what the user has to do: 1. nothing at all (filter simply appends text, for example timestamp) 2. supply an argument - for filters like file, line taking __FILE__ etc 3. 2. + supply comparation logic and run-time value. this is case of levelling logged text and filtering out messages > certain level. it depends on needs of user and is specified fully by the mpl::vector. the run-time values of course requires shared access among threads, so protecting resources has to be done carefully. ordinary mutex is too much, spinlock fits better.
- 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?
no he will _NOT_, that is the beauty ;)) if he still do, let him use log4jpp. according to my (i admit that short perhaps) experiences, this is very rarely needed. you can either modify source and recompile or use log4j++ like i said. for really simple filtering you can always use levels, context (i call that some "logic areas" of code like data flow, system message passing, etc), threadids, etc. ie simple cases already built in the chain at the compile-time. the run-time filtering logging facility should be really stupid and fast. no regexps etc. but more refined filtering for human analysis can be done by some external tool and that is where i aim to: 1. you configure your logging and you don't really pay what you dont use 2. you compile your application 3. run it 4. (optional) configure your run-time filtering values like level 5. stop the program and grab the text 6. analyse the text in some tool this tool colorizes thread ids, perform some regex replacements, ...whatever in my case it's mighty AWK, dog bless that thingy.
Other than that, I need to see more docs about what you're going to implement.
basic logging facilities. logger, some accessor (singleton?), simple appenders, few run-time filters and few sinks (file/socket).
Oh well, I don't care that much about size nowadays.
oh my goth, aren't you one of THEM? :) i'm thinking myself lately that this is kind of black plague of c++...
- pthreads are detected incorrecty. even in singlethr model mutex is required. What do you mean?
i did not use bjam for the build as i really think this tool surely comes from hell. my line is simple: g++ -I ~/devel/boost -I ~/devel/logging/ aa1.cpp but your code incorrectly detects presence of -pthread (/MT on msvc i think) switch and includes some code using pthreads even if -pthread is not present. i don't remember exactly, but $BOOST_ROOT/boost/config/...stuff.. makefiles do that for you and sets BOOST_HAS_THREADS correctly. perhaps i am wrong and it is bjam who is doing that. best regards, mojmir