October 2007 - Boost - lists.preview.boost.org

[mpi] SEEK_* defined, but shouldn't be
by Benjamin Collins 12 Dec '07

12 Dec '07

A common problem that occurs when building mpich2 is that SEEK_SET, SEEK_CUR, and SEEK_END are all defined. mpich2 (specifically mpicxx.h) requires them to be unset to avoid problems caused by both the MPI interface and stdio using them. Anyway, the suggested solution is to #undef each macro before #include <mpi.h>. I tried that in the mpi library, and it still failed to build. I also tried adding <define>MPICH_IGNORE_CXX_SEEK=1 to the mpi Jamfile. Alas, it didn't fix the problem either. The failure occurs when building release/threading-multi/collective.o How are users of mpich2+boost::mpi getting around this problem? -- Benjamin A. Collins <aggieben(a)gmail.com> http://bloggoergosum.us

3 4

[1.35.0] Tickets, Milestone, Testing
by David Abrahams 04 Dec '07

04 Dec '07

http://svn.boost.org/trac/boost/query?status=new&status=assigned&status=reo… shows all the tickets that have been assigned to the 1.35.0 milestone. Does this list have any meaning? In other words, are we actually intending to address all of these problems for 1.35, and put off other tickets for 1.35.1 or 1.36.0? IMO getting this list sorted out and handling the tickets one-by-one is the most productive way to get us from here to a successful release of 1.35.0. That may mean a number of new tickets need to be added (probably at least one for each major failure we're seeing in http://engineering.meta-comm.com/boost-regression/1_34_1/developer/issues.h… and possibly others) and it will require part of the release team to triage the whole list of tickets assigned to 1.35.0 and make some decisions to put certain tickets off for later. Also, are we running complete tests on the release branch currently? I don't see any links to test results for that part of the repo. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

11 39

[pool] Is it even possible to call release_memory() for map/list allocator pools portably?
by Scott 03 Dec '07

03 Dec '07

I have a map, declared as: typedef std::pair<int, HintPage *> PageCachePair; typedef boost::fast_pool_allocator<PageCachePair> PageCacheAllocator; typedef std::map<int, HintPage *, std::less<int>, PageCacheAllocator> PageCache; The problem is when I try to call: boost::singleton_pool<boost::fast_pool_allocator_tag, sizeof(PageCachePair)>::purge_memory(); This always returns false. The real problem (of course) is that sizeof(PageCachePair) is incorrect. The real size is determined by the rebind mechanism for the actual map node struct. However, I have no idea how to portably determine that size. Is it even possible to do this? Scott

3 2

[1.35.0] Release criteria compilers
by Beman Dawes 02 Dec '07

02 Dec '07

In doing a postmortem of the past couple of releases with Thomas Witt, he made a very strong case that testing is a major bottleneck. If developers and release managers have to wait several days to find out if a fix works, it slows progress to a crawl. One of the things we can do to eliminate that bottleneck is to cut the number of release criteria compilers down to a more manageable number, and to compilers where testing is very reliably and runs several times a day. My candidates for the release criteria compilers are: * Microsoft VC++ 8.0 on Win32 * Intel 10.0 on Win32 * GCC on Linux * GCC on Darwin I've got all of those here, so can verify test results myself if necessary. I expect people will want to add several others, and that's OK. But for this first release on our quarterly schedule, let's keep the number down to be sure we meet our targets. Comments? --Beman

24 56

Boost Logging v2
by John Torjo 26 Nov '07

26 Nov '07

Boost Loogging v2 Hi all, It's been a while - I admit, and I apologize for it. Well, finally, I'm working on version 2 of Boost Logging, taking into account your suggestions when the first version was rejected. The extra short version: It's in alpha stage. Get it from here: http://torjo.com/log2/ Without further ado, I'll present you Boost Logging Library v2, with - a much nicer separation of concepts and - a much more flexible interface. - you don't pay for what you don't use. - fits a lot of scenarios: from very simple (dumping all to one log) to very complex (multiple logs, some enabled/some not, levels, etc). - you can now define your own LOG_ macros Here are 2 small examples to show you a bit of v2's power: ----------------- Example 1: struct write_to_cout_and_file { ... }; // defining the logs logger<write_to_cout_and_file, manage_enabled_no_ts> g_single_log("out.txt"); #define L_(x) if ( g_single_log) g_single_log.process_msg()(x) // code L_("reading word " + word); ----------------- Example 2: struct write_to_file { ... }; struct write_to_cout { ... }; struct write_to_dbg { ... }; // defining the logs typedef process_msg< ostream_like_return_str<>, write_to_cout> processor_cout; typedef process_msg< ostream_like_return_str<>, write_to_file> processor_file; typedef process_msg< ostream_like_return_str<>, write_to_dbg> processor_dbg; logger<processor_cout, manage_enabled_no_ts> g_log_app; logger<processor_file, manage_enabled_no_ts> g_log_err("err.txt"); logger<processor_dbg, manage_enabled_no_ts> g_log_dbg; #define LAPP_ if ( !g_log_app) ; else g_log_app->read_msg().gather().out() #define LERR_ if ( !g_log_err) ; else g_log_err->read_msg().gather().out() #define LDBG_ if ( !g_log_dbg) ; else g_log_dbg->read_msg().gather().out() // code LAPP_ << idx << " : reading word " << word; LERR_ << "error at " << idx << ", while reading " << word; LDBG_ << "debug info: " << idx << ", reading " << word; ----------------- The above was the short version. You can also look at the test_*.cpp files, to see some more examples of how you can use the library. Download it here : http://torjo.com/log2/ Long version follows: First, a bit about the workflow: Step 1: Filtering the message Step 2: Gathering the message Step 3: Writing the message Step 1: Filtering the message In order to be efficient, before anything happens to the message, we see if the log it's written to, is enabled. If so, we process the message. If not, we ignore all of the message. This is rather easy, with constructs like this: #define L_(x) if ( g_single_log) g_single_log.process_msg()(x) #define L_ if ( !g_log_app) ; else g_log_app->read_msg().gather().out() Step 2: Gathering the message Now, that we know the log is enabled, all the message is gathered. This depends on how you write the message. For instance, you can gather it in one step, if you want to offer a syntax like this: L_("this is my message"); Or, you can offer syntactic sugar: i = 100; L_ << "this is " << i << " times better that the average bear... "; In this case, you'll gather all info in a stream of some kind. Or, you can have more data besides the message string, like: module name, severity of message, category, etc: L_(fatal,"chart","Can't find the ChartX control"); Step 3: Writing the message Now all info about the message is gathered. You can write it to its destination(s). What you wanna do with a message, is completely up to you. The library will offer you possibilities. You can go for the extremely easy way, and just have a functor which dumps the message somewhere, like this: struct write_to_cout { void operator()(const std::string & msg) const { std::cout << msg << std::endl ; } }; Or: struct write_to_file { typedef boost::shared_ptr<std::ofstream> ptr; write_to_file(const std::string & filename) : m_out(new std::ofstream(filename.c_str())) {} void operator()(const std::string & msg) const { (*m_out) << msg << std::endl ; } mutable ptr m_out; }; Or, you can choose to Format and/or write your message to Destinations (these will be explained later) Download it here : http://torjo.com/log2/ ------------------------------------------------------ Logger objects For each log you want, you'll have a logger object. Note that "log" is a concept - several logs can write to the same file and/or one log can write to multiple destinations. I use the term "log" to identify a type of log message you want to write -- for example, you can have a "debug log" for writing debug messages; an "info" log, for writing informations, and so on. The fact that they might end up writing to the same destinations, is completely transparent to the user, as it should. A logger object contains 2 things: - a filter: an is_enabled() function - to find out if it's enabled. - a process_msg() object - this contains the logic of what to do with the message, if the log is enabled. The 2 concepts are orthogonal - Andrei would call them "policies" ;) The process_msg() is the object that will process the message if the log is enabled - it executes steps 2 and 3. How this happens, is completely up to you - when you define your macros (more on this later). ------------------------------------------------------ Filtering and Log Levels I have implented several filters: see filter.hpp file: - manage_enabled_no_ts - filter (not thread-safe) - always_enabled - enable logs at compile time - always_disabled - disable logs at compile time - debug_enabled, release_enabled - manage_enabled_ts - thread-safe filter - etc. Using v2, you don't really have to use Log Levels, if you don't wish (see examples above) A logged message can have an associated Log Level. By default we have these levels: info (smallest level), warning , debug , error , fatal (highest level) Depending on which level is enabled for your application, some messages will reach the log: those messages having at least that level. For instance, if info level is enabled, all logged messages will reach the log. If warning level is enabled, all messages are logged, but the warnings. If debug level is enabled, messages that have levels debug, error, fatal will be logged. Note that there's an example of using Log Levels provided with the code. ------------------------------------------------------ Usage syntax / Macros Once you've set up what each of your logs does (writes to), it's a must to have an easy and straightforward way to write to your logs - logging can be fun. While you can write directly to your logs, like this: if ( !g_log_app) ; else g_log_app->read_msg().gather().out() << "coolio!" << std::endl; Usually you'll prefer to have some macros to help you write less and especially avoid being error-prone. In the previous version, you've asked to be able to write your own macros - well, you are. And it's waaaay easier than before: If you have a logger object, to test if it's enabled, call its operator bool(). To see if it's not enabled, call its operator! I will provide some helpers in the future - they're not there yet. ------------------------------------------------------ Logger objects and macros So, to define a log macro, you'll say something like this: logger<some_processor, some_filter_class> g_log; #define L_ if ( !g_log) ; else g_log->... Note that "g_log->" is equivalent to "g_log.process_msg()->" (syntactic sugar) What follows after "..." is all up to you. For example, you can just get the message, and call a functor: struct write_to_cout { void operator()(const std::string & msg) const { std::cout << msg << std::endl ; } }; logger<write_to_cout, manage_enabled_no_ts> g_single_log; #define L_(x) if ( g_single_log) g_single_log.process_msg()(x) And in code you'll say things like L_("some great message"); Or, you can use something a bit more complex, which will gather a message written using "<<", and then call a functor. I've already implemented this class: typedef process_msg< ostream_like_return_str<>, write_to_cout> processor_cout; logger<processor_cout, manage_enabled_no_ts> g_log; #define L_ if ( !g_log) ; else g_log->read_msg().gather().out() And in code you'll say things like: L_ << "this" << " is " << "cool"; Or you can implement your own process message class. ------------------------------------------------------ Using process_msg() Your process_msg class can hold context. And you can also manipulate logs in code: logger<...> g_log; g_log->my_great_log_manipulator(); Thus, you can create your own process message handler classes. ------------------------------------------------------ Formatters and/or destinations In my previous version, they were called modifiers and appenders. So, after the message has been gathered (step 2), we do the writing (step 3). In step 3, if you use the "format_write" class, you can choose to add formatters and/or destinations. A formatter is a functor that formats the message - for instance, it can prepend the current time, it can prepend the index, or thread ID, or append an Enter. A destination is a location where a message can be written, like: console, a file, a socket, etc. Dealing with formatters/destinations is easy: once you have a format_write object, just use: void add_formatter(formatter fmt) void del_formatter(formatter fmt) void add_destination(destination dest) void del_destination(destination dest) In the previous version, the formatters were called first, and destinations last. Now you have more control. However, this is not thoroughly tested - need to work more on this. ------------------------------------------------------ Examples. I've provided a few examples - you'll find them in the "tests" directory. The code compiles and was tested on VC8. Am still working on formatters and destinations. I'm planning to host it on sf.net. Feedback and comments are welcome. Again, you'll find the library here: http://torjo.com/log2/ -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right

3 5

[interprocess] Are there any pre-built docs about (+patch)?
by Darren Garvey 15 Nov '07

15 Nov '07

I can't currently build the interprocess docs (on windows, with MSVC9 beta2) because I'm getting an 'Access is denied' error. I have the latest xslt-proc binaries, which I thought solved this problem. It's failing at the doxygen stage so it might be a different problem altogether. There was also a missing space between two [endsect] tags, which caused it to fail when converting the quickbook source. I've put the simple patch in trac as ticket #1330. << BUILD_OUTPUT C:\cc\src\boost\trunk\libs\interprocess\doc>bjam <snip> ...patience... ...found 1114 targets... ...updating 7 targets... quickbook.quickbook-to-boostbook ..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\interprocess.xml Generating Output File: ..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\interprocess.xml doxygen-action ..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\autodoc-xml.xml-dir The system cannot find the file specified. Access is denied. del /f /q "..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\autodoc-xml\*.xml" & "L:/usr/bin/X11/doxygen" ..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\autodoc-xml.doxyfile && echo "Stamped" > "..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\autodoc-xml.xml-dir" ...failed doxygen-action ..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi\autodoc-xml.xml-dir... ...skipped <p..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi>autodoc-xml.doxygen for lack of <p..\..\..\bin.v2\libs\interprocess\doc\msvc-9.0\debug\threading-multi> autodoc-xml.xml-dir... ...skipped <p..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi>autodoc-xml.boostbook for lack of <p..\..\..\bin.v2\libs\interprocess\doc\msvc-9.0\debug\threading-multi> autodoc-xml.doxygen... ...skipped <p.>autodoc.xml for lack of <p..\..\..\bin.v2\libs\interprocess\doc\msvc-9.0\debug\threading-multi> autodoc-xml.boostbook... ...skipped <p..\..\..\bin.v2\libs\interprocess\doc\msvc- 9.0\debug\threading-multi>interprocess.docbook for lack of <p.>autodoc.xml.. . ...skipped <phtml>standalone_HTML.manifest for lack of <p..\..\..\bin.v2\libs\interprocess\doc\msvc-9.0\debug\threading-multi> interprocess.docbook... ...failed updating 1 target... ...skipped 5 targets... ...updated 1 target... << BUILD_OUTPUT So, in the meantime, are there any docs online? The old link I found http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/index.ht… doesn't work anymore. Cheers, Darren

3 4

Boost.Build documentation pages
by Vladimir Prus 13 Nov '07

13 Nov '07

Over at boost.org there's a page for Boost.Build, at: http://www.boost.org/tools/build/v2/index.html the content of which is exactly what was in the last Boost release. There's another page for Boost.Build, namely http://boost.org/boost-build2, content of which is regenerated nightly, using SVN state. The first page, generally, is outdated and wrong. For example, now it points a Milestone 11 downloads while current version of Boost.Build is M12, talks about CVS (and links to a page that does not say how to get anything from either CVS or SVN), points to development roadmap that is totally inaccurate, and so on. Generally, both the download and documentation links at http://boost.org/boost-build2 will yield better results to a user. Are there any objections to making the up-to-date docs page the one most easily found, and making docs corresponding to the last release only found via some "doc archive", or not accessible at all? (Rene's working on new website, so how this is implemented technically is separate question, I'm asking only about user-visible effect). - Volodya

3 4

[interprocess] Atomic ops supports for Alpha processors.
by Markus Schöpflin 09 Nov '07

09 Nov '07

Hello, attached patch introduces support for the atomic ops needed by interprocess on Tru64/CXX/Alpha. It currently misses support for atomic add and sub, but those are not used right now. There are a few issues I would like to raise regarding the atomic operations: 1) Currently it is not specified whether an atomic operation implies a memory barrier or not. This should be explicitly stated. 2) atomic_sub32 does not return the old value, but atomic_add32 does. This seems inconsistent to me. 3) Has the use of the low level atomic ops API as proposed in WG21/N2047 (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html) been considered. If yes, why has it been rejected? If no, would it makes sense to use this API? 4) Is there a need for an atomic ops boost library? I seem to remember that other libraries need atomic ops as well. Regards, Markus Index: atomic.hpp =================================================================== --- atomic.hpp (revision 40078) +++ atomic.hpp (working copy) @@ -436,6 +436,82 @@ } //namespace interprocess{ } //namespace boost{ +#elif defined(__osf__) + +#include <machine/builtins.h> +#include <c_asm.h> + +namespace boost{ +namespace interprocess{ +namespace detail{ + +//! Atomically increment an apr_uint32_t by 1 +//! "mem": pointer to the object +//! Returns the old value pointed to by mem +inline boost::uint32_t atomic_inc32(volatile boost::uint32_t *mem) +{ return __ATOMIC_INCREMENT_LONG(mem); } + +//! Atomically decrement an boost::uint32_t by 1 +//! "mem": pointer to the atomic value +//! Returns false if the value becomes zero on decrement, otherwise true +inline bool atomic_dec32(volatile boost::uint32_t *mem) +{ return __ATOMIC_DECREMENT_LONG(mem); } + +// Rational for the implementation of the atomic read and write functions. +// +// 1. The Alpha Architecture Handbook requires that access to a byte, +// an aligned word, an aligned longword, or an aligned quadword is +// atomic. (See 'Alpha Architecture Handbook', version 4, chapter 5.2.2.) +// +// 2. The CXX User's Guide states that volatile quantities are accessed +// with single assembler instructions, and that a compilation error +// occurs when declaring a quantity as volatile which is not properly +// aligned. + +//! Atomically read an boost::uint32_t from memory +inline boost::uint32_t atomic_read32(volatile boost::uint32_t *mem) +{ return *mem; } + +//! Atomically set an boost::uint32_t in memory +//! "mem": pointer to the object +//! "param": val value that the object will assume +inline void atomic_write32(volatile boost::uint32_t *mem, boost::uint32_t val) +{ *mem = val; } + +//! Compare an boost::uint32_t's value with "cmp". +//! If they are the same swap the value with "with" +//! "mem": pointer to the value +//! "with" what to swap it with +//! "cmp": the value to compare it to +//! Returns the old value of *mem +inline boost::uint32_t atomic_cas32 + (volatile boost::uint32_t *mem, boost::uint32_t with, boost::uint32_t cmp) +{ + // Notes: + // + // 1. Branch prediction prefers branches, as we assume that the lock + // is not stolen usually, we branch forward conditionally on success + // of the store, and not conditionally backwards on failure. + // + // 2. The memory lock is invalidated when a branch is taken between + // load and store. Therefore we can only branch if we don't need a + // store. + + return asm("10: ldl_l %v0,(%a0) ;" // load prev value from mem and lock mem + " cmpeq %v0,%a2,%t0 ;" // compare with given value + " beq %t0,20f ;" // if not equal, we're done + " mov %a1,%t0 ;" // load new value into scratch register + " stl_c %t0,(%a0) ;" // store new value to locked mem (overwriting scratch) + " bne %t0,20f ;" // store succeeded, we're done + " br 10b ;" // lock has been stolen, retry + "20: ", + mem, with, cmp); +} + +} //namespace detail{ +} //namespace interprocess{ +} //namespace boost{ + #else #error No atomic operations implemented for this platform, sorry!

6 22

Boost Exception and support for cloning
by Emil Dotchevski 09 Nov '07

09 Nov '07

In the Boost Exception review process, several people have expressed the opinion that since boost::exception (part of the proposed library) is designed to act as a base class for all Boost exceptions, it should also support cloning. This can be done by adding a clone() virtual function to boost::exception. There are several issues we have to consider. First, should clone() be pure virtual, which would require all deriving exceptions to implement it? This can be achieved by modifying boost::throw_exception to throw a type that derives from the passed exception type and implements clone(). If we go that route, we must make sure that Boost does not contain a "naked" throw statement (that is, a throw that does not call boost::throw_exception.) This should be fine, since Boost libraries are required to call boost::throw_exception anyway. However, the functionality provided by boost::exception would be desirable for user code as well, and thus it would make sense for user-defined exception types to derive it. Which raises my second question: should then user code also be required to throw exceptions by calling boost::throw_exception? Emil Dotchevski

5 11

reference_wrapper() and operator()()
by Thorsten Ottosen 06 Nov '07

06 Nov '07

Dear reference wrapper authors, Is there any good reason that boost::reference_wrapper() does not provide a forwarding operator()(), so that we may use it to pass function objects by reference to algorithms? best regards -Thorsten

5 7