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

boost/config/suffix.hpp: spurious BOOST_HAS_THREADS with g++ 3.4
by Christoph Ludwig 03 Jul '04

03 Jul '04

While testing gcc 3.4 (on a x86 PC running Linux), I encountered linker errors due to missing pthread symbols, even though my program is single threaded. I found that some translation units using boost::shared_ptr included boost/detail/lwm_nop.hpp whereas other translation units included boost/detail/lwm_pthreads.hpp. I didn't observe any errors with gcc 3.3.x. The problem turns out to be that gcc 3.4 defines the preprocessor variable _REENTRANT if certain standard library headers are included even if the compiler is *not* called with the '-pthread' command line option. The following test exhibits this behavior and shows that it causes BOOST_HAS_THREADS to be erroneously defined in boost/config/suffix.hpp if, e.g., the standard header string is included: cludwig@lap200:~/C++/gcc3.4/tmp> g++ -v Lese Spezifikationen von /opt/gcc/gcc-3.4.0/lib/gcc/i686-pc-linux-gnu/3.4.0/specs Konfiguriert mit: ../gcc-3.4.0/configure --prefix=/opt/gcc/gcc-3.4.0 --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar --enable-concept-checks --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch Thread-Modell: posix gcc-Version 3.4.0 cludwig@lap200:~/C++/gcc3.4/tmp> cat test-BOOST_HAS_THREADS.cc #if defined(WITH_STRING_HEADER) # include <string> #endif #include <boost/config.hpp> #if defined(__MT__) # warning "__MT__ defined" #endif #if defined(_MT) # warning "_MT defined" #endif #if defined(_REENTRANT) # warning "_REENTRANT defined" #endif #if defined(_PTHREADS) # warning "_PTHREADS defined" #endif #if defined(BOOST_HAS_THREADS) # warning "BOOST_HAS_THREADS defined" #endif cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ test-BOOST_HAS_THREADS.cc cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ -DWITH_STRING_HEADER test-BOOST_HAS_THREADS.cc test-BOOST_HAS_THREADS.cc:16:4: Warnung: #warning "_REENTRANT defined" test-BOOST_HAS_THREADS.cc:24:4: Warnung: #warning "BOOST_HAS_THREADS defined" I have no idea what the gcc developers recommend in order to detect multi-threading support or if this should be reported to the gcc developers as a bug. But it will certainly break many programs using Boost. A user can work around this problem by either including boost/config.hpp before any other headers (even Boost headers since boost/lexical_cast.hpp, for example, includes string before boost/config.hpp). Or the user builds everything with MT-support, even if the program itself is single threaded. Neither workaround is satisfying. Regards Christoph PS: FWIW, I could trace back the problem to a change in include/c++/i686-pc-linux-gnu/bits/gthr-default.h. This change was discussed in http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01607.html. -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

4 21

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

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

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

01 Jul '04

> 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.

2 1

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

01 Jul '04

[Christopher Currie] In the need of extreme memory efficiency and speed: I already have, from prior use, a scoped_try_lock 'l' around my mutex, currently unlocked. I need to lock my mutex in a blocking fashion. I do not wish to pay the memory and time cost to create an instance of scoped_lock just to do this. I therefore call 'l.lock()' and not 'l.try_lock()'. [Batov, Vladimir] I am sorry but I am far from being convinced that "extreme memory efficiency" can be achieved by saving on one lock. Locks are very transient creatures and created on the stack. Commonly the stack is predefined by OS regardless if you use it or not. Consequently, even when you do not create another object on the stack, that memory is not available to you for anything else anyway. Even if it is, I greatly doubt that that approach is the right approach to achieve efficiency. The common approach would be to worry about the right design first and foremost, then run profilers/monitors/tests to see where we actually can save memory/gain performance. Twisting design for the sake of perceived performance/memory gains is often (I'd say always) a very bad idea. Even if you do not buy into my arguments in the prev. paragraph, you'll probably agree it'll be unfair to expect that the majority of library users and overall general-purpose library design need to pay the price of accommodating your very specific requirements. For example, general memory allocation is often slow for me. Then, I write my own special memory allocator. I am not asking for the general-purpose allocator to be changed. ... [Christopher Currie] Constructor parameters are, admittedly, a different discussion, and most of them boil down to syntactic sugar for a non-locking constructor and a call to some locking operation, blocking or otherwise. But (IMO) it's a useful syntactic sugar that *can* if used properly make programs less cumbersome to construct without sacrificing correctness or clarity. [Batov, Vladimir] I am not against syntactic sugar if it is in line with what is reasonably expected from a class. However, I am against syntactic sugar which is not relevant to class functionality. Like I am happy if I can simply give my credit card to a taxi driver and not worry about having cash. However, I am not sure if I'd like that driver singing. As far as S/W design is concerned, I'd prefer a taxi driver class (with its responsibilities) and a singer class (with its responsibilities). We all know how to blend those two classes if we ever need that.

2 1

min, max, GCC 2.95.3, and STLport
by Doug Gregor 01 Jul '04

01 Jul '04

The new handling of min/max seems to break under GCC 2.95.3 with STLport. I'm not quite sure _why_ it doesn't work (I don't have the compiler around), but you can see the failure here: http://tinyurl.com/ytdlf Perhaps someone with that compiler/lib combination could get preprocessed output for the problem area so we could see what's happening? Doug

4 5

ccref
by alnsn＠yandex.ru 01 Jul '04

01 Jul '04

This is not a typo, I'm trying to emphasize that ref, cref, ... sequence lacks one element which imposes more strict requirements on its argument. According to IQ tests logic that sequence should be continued with ccref :) If seriously, cref allows silent binding of a temporary to a reference. Apparently, this is not always fine. Inspired by N1610 (thanks to Dave and Gary) I've tried to detect both const and non-const rvalues. I didn't yet opened my copy of the standard to check it but the code seems to work on g++ 3.2.2, g++ 3.4.0, Intel 8.0 (all under linux) and Comeau online. #include <boost/ref.hpp> template<class T1, class T2> struct enable_if_same { }; template<class T> struct enable_if_same<T,T> { typedef int type; }; template<class T> boost::reference_wrapper<T const> const ccref(T volatile& r, typename enable_if_same<T,T const>::type = 0) { return boost::reference_wrapper<T const>(const_cast<T const&>(r)); } struct convertible_to_int { operator int() const { return 0; } }; template<class T> boost::reference_wrapper<T const> const ccref(T const volatile& r) { return boost::reference_wrapper<T const>(const_cast<T const&>(r)); } int rvalue() { return 0; } int const const_rvalue() { return 0; } int main() { int i; int const j = 0; ccref(i); ccref(j); // Try uncommenting any of these lines: // ccref(rvalue()); // ccref(const_rvalue()); } -- Alexander Nasonov

3 4

Links at ACCU
by David Abrahams 01 Jul '04

01 Jul '04

Hi, I recently got this request from the ACCU website admins: Please take a look at www.accu.org/terse/cpp.htm and let me know how the Boost library/people would like to be represented on www.accu.org/terse/cpp.htm. So I figured I'd ask. Anyone have an opinion? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

5 4

RE: [boost] Re: Cvs tag dependency
by Rozental, Gennadiy 01 Jul '04

01 Jul '04

> "Rozental, Gennadiy" <gennadiy.rozental(a)thomson.com> writes: > > > Hi, > > > > Inn a light of recent discussion on earlier freezing, I > have following > > question/proposition: > > > > Is it exist in Boost.Build or could we add feature that allow us to > > specify cvs tag dependency as a dependency grist? > > I _think_ what you're proposing is interesting, but the means > of getting there may be completely inappropriate for > Boost.Build, if I understand it at all. Why don't you try to > say what you're trying to accomplish without trying to design > the Boost.Build feature? I want to be able to use regression testing facility not only for HEAD cvs state. > Are you trying to get cvs checkout > actions into the build system? Namely. I want build system be aware about different versions of files/components and want to be able to specify which version I prefer to use for this particular test. > If so, why? What's wrong with doing > > cvs update -rwhatever_tag > before kicking off the test? Nothing. I just want it happened automatically on a computer that performs regression testing, depends on a rule defined in a Jamfile. > Dave Abrahams Gennadiy.

3 2

[MPL] rational_c and fixed_c
by Cromwell Enage 30 Jun '04

30 Jun '04

A while back it was mentioned that boost::mpl::rational_c and boost::mpl::fixed_c needed redesigning. Before I attempt to tackle this task anymore than I already have, I should have some questions answered. 1. For those compilers for which BOOST_NO_LIMITS is defined, I've learned that there is no way to include a floating-point number in an integral constant expression. Does this mean that no matter how I define fixed_c::value, I cannot pass fixed_c as a template argument to a metafunction that ordinarily takes integral_c as input? Do I have to duplicate the functionality as a result? If so, what should be the naming convention for these new metafunctions? 2. Should I define fixed_c in terms of rational_c, to reduce the amount of functionality I may need to duplicate? Something like this: template <typename IntType, IntType N, IntType PowerOf10> struct fixed_c { typedef rational_c<IntType,...,...> type; }; 3. Eventually the compile-time rational-number representation will need to be converted to a runtime floating-point value. Should I define this conversion function within rational_c (which means an additional template parameter, with either function or class scope, defining the return value type), within a wrapper struct, or somewhere else? And how? 4. I only have to deal with rational numbers, right? I don't have to worry about accurately representing a transcendental number or a complex-number expression? TIA! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer

3 7