July 2004 - Boost - lists.preview.boost.org

CVS Fingerprint problems
by Fernando Cacciola 02 Jul '04

02 Jul '04

Hi, I'm trying to commit something to CVS but I get a warning from TortoiseCVS saying that the server fingerprint has changed. This is wrong right? TIA Fernando Cacciola SciSoft

2 2

logging library
by John Torjo 02 Jul '04

02 Jul '04

Dear boosters, Finally, found some time to work on the logging library ;) (for those interested - find it at http://groups.yahoo.com/group/boost/files/logging.zip or http://www.torjo.com/code/logging.zip) note: this first draft works only for Win32 :( In short, it makes it very easy to log messages, while being efficient. And on top of that, it's thread-safe. Table of contents: ****** Declaring/defining logs ****** Log hierarchies ****** Modifier/ Log functions ****** Enabling/disabling of logs ****** Example ****** Declaring/defining logs Every log has: - a unique ID, by which you refer when you write to it - a name, by which you can modify its behavior (for example, enabling/disabling). The name is very useful so that you can manipulate multiple logs at once (for instance, disable multiple logs at once) and to be externally known - to easily manipulate logs at run-time. Also, this way is also easier to form hierarchies of logs (see below). Cutting to the chanse: // declare a log, in a header file BOOST_DECLARE_LOG(dbg) // define the log, in a source file BOOST_DEFINE_LOG(dbg, "app.dbg") // writing to the log BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; ****** Log hierarchies Logs can be hierarchical. In a hierarchy, a log inherits all anscestors' behaviors. Log A is said to be a descendant of Log B if when B's name starts with A's name (example: "app.charts.gui.dbg" is a descendant of "app.charts", but not a descendant of "app.err") When manipulating logs, you're always manipulating a hierarchy - the wildcard '*' stands for "anything" - see below. ****** Modifier/ Log functions When a message is written to a log, the following will happen: - first, check if the log is enabled. If so, continue. Otherwise, do nothing. - run all modifiers for this message - run all log functions for this message A modifier is a function that can modify the original message before it's printed to any destination. Examples can be: prefix the message with the current time, or prefix the message with the current thread ID. The log function is a function that will actually print this message to a destination. An example: void write_to_cout(const std::string &, const std::string &msg) { std::cout << msg; } When setting modifier/log functions, you're manipulating hierarchies of logs. Example: // add this modifier to all logs that start with "app" name add_modifier_func("app*", &write_prefix); // write all messages to cout add_log_func("*", write_to_cout); ****** Enabling/disabling of logs By default, all logs are enabled. You can specifically enable/disable some of them - wildcards work. Example: // disable all logs disable_logs("*"); // enable all dbg logs enable_logs("*dbg*"); Note that enabling/disabling is VERY EFFICIENT. In case a log is not enabled, the code after BOOST_LOG(...) is not executed AT ALL. Example: BOOST_LOG(app) << some_time_consuming_msg << std::endl; If 'app' is disabled, some_time_consuming_msg will not be executed. ****** Example // full sample found in logging.zip // Modifiers for all: // [type_of_message] original_message append_enter_if_needed add_modifier_func("*", &prefix_time, std::numeric_limits<int>::max() ); add_modifier_func("*", &append_enter); // Modifiers for app and its ascendants // <time> [type_of_message] original_message append_enter_if_needed add_modifier_func("app*", &write_prefix); // Modifiers for "app" only // <time> [Thread ID] [type_of_message] original_message append_enter_if_needed add_modifier_func("app", &prepend_thread_id, 0); // Log Functions // all messages are written to cout add_log_func("*", write_to_cout); // "app*" messages are written to file as well add_log_func("app*", write_to_file); // 'app' only and dbg messages are written to Output Debug Window as well add_log_func("app", write_to_dbg_wnd); add_log_func("*dbg*", write_to_dbg_wnd); int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing" << i << '-' << j << '-' << k; // written to both cout & the file & Output Debug Window BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; BOOST_LOG(warn) << "Logged-on Users approach max. limit"; BOOST_LOG(err) << "Too many users!"; BOOST_LOG(charts::gui) << "Creating main window" << std::endl; BOOST_LOG(charts::dbg) << "A debug msg coming from {charts} module" ; BOOST_LOG(charts::gui) << "Destroying main window" << std::endl; // disable all descendants of 'app' (not the 'app' itself) disable_logs("app.*"); BOOST_LOG(dbg) << "this won't be written" << std::endl; BOOST_LOG(app) << "However, this msg. will" << std::endl; enable_logs("app.dbg"); // specifically, only dbg log is enabled back now BOOST_LOG(dbg) << "this will be written - this log just got enabled" << std::endl; BOOST_LOG(err) << "this still won't be written" << std::endl; enable_logs("app.*"); disable_logs("app.dbg"); // now, all logs are back to the 'enabled' state BOOST_LOG(err) << "this will be written - all logs are enabled" << std::endl; // disable all logs disable_logs("*"); BOOST_LOG(err) << "this won't be written" << std::endl; BOOST_LOG(app) << "neither will this" << std::endl; BOOST_LOG(dbg) << "or this..." << std::endl; BOOST_LOG(warn) << "or this..." << std::endl; BOOST_LOG(info) << "or this..." << std::endl; // enable all dbg logs enable_logs("*dbg*"); BOOST_LOG(app) << "this won't be written" << std::endl; BOOST_LOG(dbg) << "this will be written" << std::endl; BOOST_LOG(info) << "this won't be written" << std::endl; // enable info log enable_logs("*info*"); BOOST_LOG(info) << "a simple info" << std::endl; /*** Console 18:59:44 [app] [Thread 1384] testing1-2-3 18:59:44 [app.dbg] this is a debug message, i=1 18:59:44 I just wanted to tell you something.... 18:59:44 [app.warn] Logged-on Users approach max. limit 18:59:44 [app.err] Too many users! 18:59:44 Creating main window 18:59:44 A debug msg coming from {charts} module 18:59:44 Destroying main window 18:59:44 [app] [Thread 1384] However, this msg. will 18:59:44 [app.dbg] this will be written - this log just got enabled 18:59:44 [app.err] this will be written - all logs are enabled 18:59:44 [app.dbg] this will be written 18:59:44 a simple info */ /*** Output Debug Window 19:00:03 [app] [Thread 1384] testing1-2-3 19:00:03 [app.dbg] this is a debug message, i=1 19:00:03 A debug msg coming from {charts} module 19:00:03 [app] [Thread 1384] However, this msg. will 19:00:03 [app.dbg] this will be written - this log just got enabled 19:00:03 [app.dbg] this will be written */ /*** out.txt file 19:00:03 [app] [Thread 1384] testing1-2-3 19:00:03 [app.dbg] this is a debug message, i=1 19:00:03 [app.warn] Logged-on Users approach max. limit 19:00:03 [app.err] Too many users! 19:00:03 [app] [Thread 1384] However, this msg. will 19:00:03 [app.dbg] this will be written - this log just got enabled 19:00:03 [app.err] this will be written - all logs are enabled 19:00:03 [app.dbg] this will be written */ There's some more work - the docs also ;) , but I'm pretty happy with the first draft. What do you all think? Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

5 10

[program_options] Darwin/Unicode/DLL failure
by Vladimir Prus 02 Jul '04

02 Jul '04

Hello! As shown in http://tinyurl.com/2q5xe that program_options fails unicode_test_dll on darwin. It's the only failure there, does not happen with statically linked version, and happens at runtime. For some reason conversion from or to unicode fails. Since it's runtime failure, I have no idea what could be wrong, and why it only happens in DLL. I'd really appreciate if somebody has a clue. Even knowning what's being converted, and at which character the codecvt facet fails might help. Thanks in advance, Volodya

1 0

Re: Learning boost::MPL
by Dan 02 Jul '04

02 Jul '04

Thanks Maxim, I appreciate the help. I tried the code out, it works well, but I must confess that I don't understand how it works. It seems you start it at begin+1. I don't know why but it's probably related to the next question. What is happening on this line? mpl::plus<mpl::deref<mpl::_2>, mpl::_1> As near as I can tell you deref the iterator in <_2> and add that with _1. How does this _1 and _2 stuff work anyway? Thanks again! -Dan

3 2

logging library v1.1 - with documentation!
by John Torjo 02 Jul '04

02 Jul '04

Dear boosters, Worked some more on the logging library, and here's what's new: - added ***documentation*** - added samples - made static library (improved compilation times) - added efficient thread-safe logger, which does the logging on a dedicated thread (in order to be as fast as possible, it caches multiple log messages - which could be coming from multiple threads, and has a dedicated thread, which once at X milliseconds, writes them) Get it from: http://groups.yahoo.com/group/boost/files/logging.zip or http://www.torjo.com/code/logging.zip Looking forward to your feedback. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

3 5

min/max, revolutions
by Eric Niebler 02 Jul '04

02 Jul '04

I've made one more small tweak to the min/max fix. I have relocated the BOOST_USING_STD_MIN and BOOST_USING_STD_MAX macros to their rightful place in the config headers and removed boost/minmax.hpp. I have fixed all the code affected by this change. I have also changed the coding guidelines to say to #include config.hpp instead of minmax.hpp. I have also (hopefully!) fixed the problem with gcc-2.95/STLPort, although I don't have that platform so I couldn't test my changes. Thanks for your patience while I work these kinks out. -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 01 Jul '04

01 Jul '04

Or, maybe even, try_scoped_lock : private basic_lock { ... try_scoped_lock (mutex& m) : basic_lock(m, 0) {} bool try_lock() { basic_lock.try_lock(); } // No lock() for try_scoped_lock } Then, user-oriented interfaces would be pristine clean for average users and the majority of uses without affecting/complicating underlying implementation and disadvantaging the advanced/tricky users. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Batov, Vladimir Sent: Friday, 2 July 2004 7:40 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? I am thinking maybe technically it would be much easier and cleaner to implement one basic_lock (modeled on the current timed_lock) and then provide specializations (you see, I am avoiding "refinement" :-) ) of it to the user like: try_lock : public basic_lock { ... try_lock(mutex& m) : basic_lock(m, 0) {} } Then, 1. underlying implementation would be much simpler and without duplication as it'd always operate with basic_lock (good for maintainers/implementers); 2. average users would still have friendly and simple interface; 3. advanced users might do much more tricky stuff by simply cutting to the bone and using basic_lock. Just a thought. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Batov, Vladimir Sent: Friday, 2 July 2004 7:25 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition) template <typename ScopedLock> bool timed_wait(ScopedLock& lock, const xtime& XT); Looking at the code it does appear to require timed_lock either: template <typename L> bool timed_wait(L& lock, const xtime& xt) { if (!lock) throw lock_error(); return do_timed_wait(lock.m_mutex, xt); } What am I missing? BTW. How can I get to have look at the development branch? I went to http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found nothing threads-related. Thanks, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? Batov, Vladimir wrote: >>Well, as you point out, try_lock is like a timed_lock with >>time = 0, and lock is like a timed_lock with time = infinity, >>so why not give timed_lock both lock() and try_lock() >>methods as shorthand notation for lock(m, t=0) and >>lock(m, t=infinity)? > > > [Batov, Vladimir] Because, in my view, it violates the fundamental (and > I think widely accepted) OO design principle (guideline?) that in simple > terms can be expressed as "one class, one responsibility". Names like > Bertrand Meyer, Herb Sutter and many others immediately come to mind. > > We can either achieve that by having a universal lock (with timed_lock > as the basis) and shorthand notations in separate derived classes (lock, > timed_lock and try_lock) or by keeping those three completely unrelated > (probably at the expense of some code/functionality duplication). I am > personally leaning towards latter, as even though technically all three > concepts are related, from the user point of view they are distinct. > > >>The argument for try_lock not having a blocking lock() method, >>which you seem to stress more often, is much clearer; I'm much >>more inclined to agree with you there. > > > [Batov, Vladimir] Thank you. I feel that it is important that every > class does what it promises to do. No more, no less. For what it's worth, heres a use case I just ran across illustrating why timed_lock should have a blocking lock() method and/or a blocking locked constructor: condition c; void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here for(;;) { //do stuff c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } } Mike _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 01 Jul '04

01 Jul '04

I am thinking maybe technically it would be much easier and cleaner to implement one basic_lock (modeled on the current timed_lock) and then provide specializations (you see, I am avoiding "refinement" :-) ) of it to the user like: try_lock : public basic_lock { ... try_lock(mutex& m) : basic_lock(m, 0) {} } Then, 1. underlying implementation would be much simpler and without duplication as it'd always operate with basic_lock (good for maintainers/implementers); 2. average users would still have friendly and simple interface; 3. advanced users might do much more tricky stuff by simply cutting to the bone and using basic_lock. Just a thought. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Batov, Vladimir Sent: Friday, 2 July 2004 7:25 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? According to the current Boost.Threads documentation timed_wait() does not require timed_lock (cut and pasted from http://www.boost.org/libs/thread/doc/condition.html#class-condition) template <typename ScopedLock> bool timed_wait(ScopedLock& lock, const xtime& XT); Looking at the code it does appear to require timed_lock either: template <typename L> bool timed_wait(L& lock, const xtime& xt) { if (!lock) throw lock_error(); return do_timed_wait(lock.m_mutex, xt); } What am I missing? BTW. How can I get to have look at the development branch? I went to http://cvs.sourceforge.net/viewcvs.py/boost/boost/development/ but found nothing threads-related. Thanks, V. -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Glassford Sent: Friday, 2 July 2004 4:35 AM To: boost(a)lists.boost.org Subject: [boost] Re: Boost.Threads: Do we need all those mutexes? Batov, Vladimir wrote: >>Well, as you point out, try_lock is like a timed_lock with >>time = 0, and lock is like a timed_lock with time = infinity, >>so why not give timed_lock both lock() and try_lock() >>methods as shorthand notation for lock(m, t=0) and >>lock(m, t=infinity)? > > > [Batov, Vladimir] Because, in my view, it violates the fundamental (and > I think widely accepted) OO design principle (guideline?) that in simple > terms can be expressed as "one class, one responsibility". Names like > Bertrand Meyer, Herb Sutter and many others immediately come to mind. > > We can either achieve that by having a universal lock (with timed_lock > as the basis) and shorthand notations in separate derived classes (lock, > timed_lock and try_lock) or by keeping those three completely unrelated > (probably at the expense of some code/functionality duplication). I am > personally leaning towards latter, as even though technically all three > concepts are related, from the user point of view they are distinct. > > >>The argument for try_lock not having a blocking lock() method, >>which you seem to stress more often, is much clearer; I'm much >>more inclined to agree with you there. > > > [Batov, Vladimir] Thank you. I feel that it is important that every > class does what it promises to do. No more, no less. For what it's worth, heres a use case I just ran across illustrating why timed_lock should have a blocking lock() method and/or a blocking locked constructor: condition c; void f(mutex m) { mutex::scoped_timed_lock l(m, locked); //always want the lock here for(;;) { //do stuff c.timed_wait(l, next_wakeup_time()); //timed_wait requires a timed_lock } } Mike _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Serialization of infinite double - from comp.lang.c++
by Jeff Flinn 01 Jul '04

01 Jul '04

I'm posting this message from Gustav Lead from comp.lang.c++ while he gets access to boost devel and/or user mailing lists. Jeff Flinn ---------------------------------- Hi all, I have trouble reading back floating point data from a file. It appears as if the tokens for positive and negative infinity (1.#INF and -1.#INF) that my implementation writes get misinterpreted (to 1.0 and -1.0) when I try to read them back in. #include <fstream> #include <limits> void somefunction() { double d_infinity = std::numeric_limits<double>::infinity(); std::ofstream output; output.open("file.txt"); output << d_infinity; output.close(); double d_test1 = 0; std::ifstream input; input.open("file.txt"); input >> d_test1; input.close(); } The contents of "file.txt" is "1.#INF". At the end of the function the value of d_test1 is 1.0 . Trying to read in more data after that will fail, because the "#INF" fragment remains in the stream. Is this a problem of my STL implementation (I am using MSVC 7.1), or do I have to make some change to my code to get this to work correctly? Thanks in advance, G L "Mike Wahler" <mkwahler(a)mkwahler.net> wrote in news:xTIEc.470$oD3.371@newsread1.news.pas.earthlink.net: > > No, this is by design. > If you want to store a special 'token' to indicate 'infinity', you'll > need to specifically parse for it. > > Typically numeric input is handled more robustly by reading a 'line' > as a string, and using conversion functions after the fact (e.g. > 'strod()' or an istringstream extractor). To check for your > 'infinity' token, just search the string for that first. > > -Mike Thanks for your answer, Mike! Unfortunatly this is not an option for me, because I am using a serialization library (Boost::Serialization currently at http://www.rrsd.com/boost/) and I have to rely on the STL stream library operators to read back all of their repective data as they wrote it into the stream and to properly restore the state of the object. Perhaps I could alter the behavior of the "ostream& operator<<(ostream&, double)" (and istream)? I think overloading would be a redefintion and is out of the question (or is it???) unless I make some kind of wrapper for doubles, but maybe it is possible to do this with locales (or facets?) ? Locales are really terra incognita for me, so I'd really like some advice if this is a viable option at all, before I try to go down that path. Any other idea for a solution would of course be just as welcome.... Thanks, GL

1 0

Re: Learning boost::MPL (Daniel Wallin)
by Dan 01 Jul '04

01 Jul '04

Hi Daniel, I tried your code as well and it works fine (it's also nice and compact) >I don't know why you are using iter_fold instead of just fold here, but >anyway: Oops, don't assume I know what I'm doing, because I don't! Yesterday was the first I ever heard of boost MPL. Whats the difference between iter_fold and fold? I replaced iter_fold with fold in your code and it works as well. Thanks, -A fellow Daniel :)

2 1