- Boost - lists.boost.org

Re: [boost] [Review] Boost.Logging: formal review
by Richard Glanmark 23 Dec '05

23 Dec '05

Some thoughts and ideas about some of the topics that has been discussed regarding the proposed Boost.Logging library. 1. Enabled/disabled logger, logging macros and efficiency The logging macro BOOST_LOG should accept two arguments instead of one. The logger and the log message. The syntax (1) BOOST_LOG(some_log) << "my message " << foo() << bar(); should be replaced with (2) BOOST_LOG(some_log, "my message " << foo() << bar()); and the macro being defined something like this (3) #define BOOST_LOG(logger, msg) \ if(logger.isEnabled()) { /* code that logs msg */ ... } Thus, disabled loggers will never take longer than simple if-statement, as long as the isEnabled() method is fast, which IMO should take no longer than comparing booleans. In the original solution (1) the method foo() will always be called, which is inefficient when the logger is disabled, in solution (2), foo() will never be called when the logger is disabled. Further more, the macro could insert extra information such as __LINE__, __FILE__ etc. If needed or wanted, the macro could of course be redefined to leave no trace of the logging. I could also envision a few other macros that for example creates a logger object on the stack that logs upon creation and destruction, a special macro to aid developers that are always compiled out of release code. Perhaps such macros is best left to the user of the library although I do think that there are common set of macros that is useful for most applications and situations and thus are good candidates for being defined in the library. 2. Filtering There has been some discussion about the ability of a library to be able to do more filtering than simple log levels, notably by Gennadiy Rozental. Gennadiy writes: > At the bare minimum it should support: > > entry level - levels set is ordered set of values indication importance of > information provided. Filtering is based on threshold. Examples: DEBUG, INFO, MAJOR > entry category - categories set is a set of unique values indicating kind of > information provided Filtering is based on masking. > Examples: ARGS, RETURN_VALUE, ERROR_LOG, DATA_FLOW, PROG_FLOW > entry keyword - keyword set is set of user defined keywords (most frequently strings) > identifying area of the program. Filtering is based on match of keywords. > Keywords usually are used to mark specific part of application. I agree that it is very important for a logging library to support this. However, I do not think that the solution is for the logging library to be aware of such special values. The library should be as simplistic as possible, with no or few assumptions about its use, at least at the basic "framework level". Only then IMO could the library accodomate various neeeds. Let me explain. If special values are introduced in the library, there will always be applications and users that lack some other special value, perhaps specific to their domain, but even more likely, to their taste and style. My proposed solution is to basically let loggers be somewhat entry (Gennadiy's definition above) unaware. Instead, let the developer be entry aware. By that I mean that the developer should log messages that belong to a specific entry category/level to a specific logger. For example, if there is a need to log and filter a RETUN_VALUE category, then a specific logger, perhaphs named RETURN_VALUE_LOGGER (or whatever), and let the user send log messages to that logger. This could look something like this: BOOST_LOG( RETURN_VALUE_LOGGER, "The return value is: " << value ); This solution also means that you have a different logger for each level, level filtering perhaps being the most common filter. For example: BOOST_LOG( debug, "some debug output " << a << foo() ); BOOST_LOG( error, "Error: " << e.what() ); where 'debug' and 'error' are loggers. Now, the drawback with this approach is that several loggers needs to be defined and configured, but as long as this is simple this should be ok. There should also be default definitions and configurations available from the library, which "sits" on top of the basic library framework. As for entry keywords (see above), I see two interpretations of Gennadiy's idea. (1) A log statement is marked with a keyword. For example: BOOST_LOGX( logger, "user defined keyword", "my log msg " << value ); Or (2), logging is filtered on what strings are contained in the log message. That is, log statements are written in the normal way by the programmer but is filtered by some mechanism where the log message is matched against certain keywords, like the grep command. For interpretation (1): My proposed solution should solve the problem. Declare a specific logger that the programmer send log statements to for the specified keyword. For interpretation (2 ): IMO the filtering mechanism should either sit on top of loggers or possibly in the appenders, or the tools that are used to view logs (e.g. grep and such). The "on top" solution would be to use specicial functions that utilizes the "lower" layer of simple loggers. It should be an extension to the log library and not be part of the core functionality (but could still be provided by a logging library). For example: BOOST_LOGX( logger, Predicate( ... ), "my log msg" << value ); Thus, the approach to filtering, based on Gennadiy's idea of various criteria is to to enable/disable loggers depending on system/users/developers needs'. Hence, enabling/disabling must be simple. Using John Torjo's solution of manipulate_log-functions this ought be relative easy. The programmer should be able to enable/disable loggers on various critiera. One solution for this would be to attach user, as well as common/default library, supplied name-value pairs to loggers and let the manipulate_log functions enable/disable loggers that meet certain criteria for these name-value pairs. For example, when defining which loggers that are available to the programmer (by himself or some other developer), a log level name-value object is attached to the loggers. The logger named 'debug' is attached with a log level of 'debug' (a literal integer value chosen carefully e.g. 0). Later on in the program, the programmer can issue the statement, using the manipulate_log-functions to enable all loggers that have a property name log level with a value greater than 'debug' and so on. Additional benefits of using this clean approach (maybe possible with Johns solution as well (?)) to loggers is that it is quite possible to have debug loggers log in one subsystem while normal logging is done in the rest of the program. Any combination is possible. The major drawback with this clean approach to loggers as I see it is the additional complexity, cognitive burden, for setting up loggers. Part of this problem should be alleviated by the library by providing a default set of loggers for common/simple/I just wanna get started -situations. Cheers, Richard Glanmark The content of this e-mail is intended only for the confidential use of the person(s) to whom it is addressed. If the reader of this message is not such a person, you are hereby notified that you have received this communication in error and that reading it, copying it, or in any way disseminating its content to any other person, is strictly prohibited. If you have received this message in error, please notify the author by replying to the e-mail immediately. NeoNet AB and its subsidiaries (NeoNet Securities AB, NeoNet Securities Inc. and NeoNet Technology AB) are unable to exercise control over the content of information contained in transmissions made via the Internet and hereby excludes any warranty as to the quality or accuracy of any information contained in this message and any liability of any kind for the information contained in it, or for its transmission, reception, storage or use in any way whatsoever.

3 2

Re: [boost] [Review] Boost.Logging: formal review
by Martin Bonner 23 Dec '05

23 Dec '05

----Original Message---- From: Richard Glanmark [mailto:Richard.Glanmark@neonet.biz] Sent: 15 December 2005 08:33 To: boost(a)lists.boost.org Subject: Re: [boost] [Review] Boost.Logging: formal review > Some thoughts and ideas about some of the topics that has been > discussed regarding the proposed Boost.Logging library. > > > 1. Enabled/disabled logger, logging macros and efficiency > > The logging macro BOOST_LOG should accept two arguments instead of > one. The logger and the log message. The syntax > > (1) BOOST_LOG(some_log) << "my message " << foo() << bar(); > > should be replaced with > > (2) BOOST_LOG(some_log, "my message " << foo() << bar()); > > and the macro being defined something like this > > (3) #define BOOST_LOG(logger, msg) \ > if(logger.isEnabled()) { /* code that logs msg */ ... } The current definition is (I believe) #define BOOST_LOG(logger) \ if(!logger.isEnabled()) {} else logger Which achieves the same ends. In particular, foo() is not called unless logging occurs. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

4 3

reactor versus proactor
by Arkadiy Vertleyb 23 Dec '05

23 Dec '05

Hi all, This is a question to networking gurus, and is on the edge of being off topic, but I am asking it here because I hope it will help me to better understand rationale behind the asio design... As was stated before, asio is based on the proactor pattern. This pattern is known for its scalability, but is difficult to port since it's based on asynchronous calls which are implemented differently (or not implemented at all) on diferent OSs. OTOH, reactor (the one based on select) seems to be easily portable, and also scalable, but its only real problem is that it doesn't utilise threads, and so it can't take an advantage of multi-processor systems. So my question is, isn't this drawback easily remedied by just placing select-ed sockets into a queue, and having multiple threads (from a thread pool) pick them up and performing the work? Wouldn't this provide comparable performance on multiple processors, with much better portability, than proactor? Thanks, Arkadiy

4 3

Review Request: pimpl
by Asger Mangaard 23 Dec '05

23 Dec '05

Hi, I would like to resubmit the pimpl library for a formal review. The suggested library can be found in the sandbox's root. Regards, Asger Mangaard

2 1

Re: [boost] bug in signals library? - segmentation fault (onlylinked) -> exit(11) called
by Oliver.Kowalke＠infineon.com 23 Dec '05

23 Dec '05

Hi, Strange - the segmentation fault disappears if I link with the debug-version of libboost_signals (-lboost_signals-gcc-d-1_33_1)! It seams to me that some assert statements contain required code (removed in release version if signals)?! >> I get an segmentation fault if I try to link against >> libboost_signals-gcc-1_33_1 or libboost_signals-gcc-mt-1_33_1! >> The application consist only of an empty main function and the binary is >> linked against the signals library. >> I've appended an output (tusc.out) of tusc (trace unix system calls) >> which indicates, that exit(11) is called and so a core dump created. > >Can you run the program under gdb debugger, and when hittin segfault >produce >backtrace with the "backtrace" command. That will be more usefull, in any >case, then syscall trace. I'm not familiar with gdb! What I did (hopefully correct): [src]$ /opt/langtools/bin/gdb32 test HP gdb 5.2 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00 and target hppa1.1-hp-hpux11.00. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 5.2 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. .. (gdb) run Starting program: /eda-home/kowalke/Projects/test/debug/src/test Program received signal SIGSEGV, Segmentation fault si_code: 0 - SEGV_UNKNOWN - Unknown Error. 0xc0017cd8 in <unknown_procedure> () (gdb) backtrace #0 0xc0017cd8 in <unknown_procedure> () warning: Attempting to unwind past bad PC 0xc0017cd8 #1 0xc0027400 in <unknown_procedure> () #2 0xc0027400 in <unknown_procedure> () Error accessing memory address 0x3e7: Bad address.

3 2

[Boost-bugs] [ boost-Patches-1169756 ] Threads add additional assert to aid in debugging join()
by SourceForge.net 23 Dec '05

23 Dec '05

Patches item #1169756, was opened at 2005-03-24 09:55 Message generated for change (Comment added) made by hxpro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1169756&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Threads add additional assert to aid in debugging join() Initial Comment: see discussion at http://article.gmane.org/gmane.comp.lib.boost.user/10093 ---------------------------------------------------------------------- >Comment By: hxpro (hxpro) Date: 2005-12-23 13:59 Message: Logged In: YES user_id=1211438 Closed its done ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-04-02 23:03 Message: Logged In: NO added in Revision: 1.20, Tue Mar 29 16:19:32 2005 UTC by glassfordm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1169756&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1115576 ] Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options]
by SourceForge.net 23 Dec '05

23 Dec '05

Patches item #1115576, was opened at 2005-02-03 17:15 Message generated for change (Comment added) made by hxpro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options] Initial Comment: Some simple fixes to make the build work... ---------------------------------------------------------------------- >Comment By: hxpro (hxpro) Date: 2005-12-23 13:58 Message: Logged In: YES user_id=1211438 Looks like its all done... ---------------------------------------------------------------------- Comment By: hxpro (hxpro) Date: 2005-02-09 09:54 Message: Logged In: YES user_id=1211438 Yes, its a templated getline that is using a bare '\n' instead of a specialised form for wchar_t or calling widen() etc. Kevin ---------------------------------------------------------------------- Comment By: Vladimir Prus (vladimir_prus) Date: 2005-02-09 09:07 Message: Logged In: YES user_id=321498 I've applied the program_options patches. Thanks. Does the compiler has the same getline problem as Comeau -- calling wide version without explicit L'\n' fails? ---------------------------------------------------------------------- Comment By: hxpro (hxpro) Date: 2005-02-07 11:08 Message: Logged In: YES user_id=1211438 N.B. The boost bind patch is now in revision 1.40 in CVS see http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/bind.hpp?r1=1.40 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1388901 ] [concept_check.hpp] remove unused variable warning in msvc
by SourceForge.net 23 Dec '05

23 Dec '05

Patches item #1388901, was opened at 2005-12-23 13:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1388901&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: [concept_check.hpp] remove unused variable warning in msvc Initial Comment: simple enough fix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1388901&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[signal] performance
by Vladimir Prus 23 Dec '05

23 Dec '05

Hi, I've just tried to measure performance of Boost.Function and Boost.Signals using the following simple program: #include <boost/function.hpp> #include <boost/signals.hpp> using namespace std; void do_nothing() {} int main() { boost::function<void (void)> f = do_nothing; void (*pf)(void) = &do_nothing; boost::signal<void (void)> s; s.connect(&do_nothing); for(int i = 0; i < 10000000; ++i) s(); return 0; } and trying calls to 's()', 'pf()' and 'f()'. The timings are, on an Athlon 1700 with g++ 3.3.5 and -O3: Function pointer: 0.05 secs Boost.Function: 0.2 secs Boost.Signals: 9.8 secs Boost.Function is 4 times slower than function pointer, which seems decent for me (not that I mind further improvement). But Boost.Signals is nearly 50 times slower that Boost.Function, and nearly 200 times slower than function pointer. Any chance this will be improved? Say, I don't care about combining the results of signals invocation, or any connection tracking -- I just want to use boost::signals as more convenient variant of vector<boost::function>. Is it possible to have some preprocessor define that throws away all advanced functionality? Or a base class, say "lightweight_signal" that has only basics? TIA, Volodya

7 10

[spirit] [1.33.1] file_iterator needs workaround for VC8
by MB 23 Dec '05

23 Dec '05

Hi, Under VC8 Express Edition: #include <functional> #include <boost/spirit/iterator/file_iterator.hpp> // greeting namespace your { struct plus { }; } namespace my { using namespace your; struct A : plus { }; // error C2872: 'plus' : ambiguous symbol } I don't know what happens, but 'using namespace std;' at <iterator/impl/file_iterator.ipp:line41> does something bad. Simplified Code: namespace standard { struct plus { }; } // almost like 'using namespace standard' under vc8? namespace fileiter_impl { // 'using-directive' here using namespace standard; // 'class template' here template< typename CharT > class std_file_iterator { }; } namespace your { struct plus { }; } namespace my { using namespace your; struct A : plus { }; // error C2872: 'plus' : ambiguous symbol } Regards, MB p-stade.sourceforge.net

1 0