November 2008 - Boost - lists.preview.boost.org

Boost C++ Library Patches (1.36.0) (from C++ Soup Blog)
by Dean Michael Berris 03 Nov '08

03 Nov '08

Hi Guys, I've recently posted some issues to the Boost Trac system. What follows is the content of my post to my blog (http://blog.cplusplus-soup.com/) regarding patches I've submitted. I hope this helps! ---->8--- For those who have been having some trouble getting some libraries to compile nicely in Boost 1.36 using GCC 4.3.2, I have posted some issues (and associatively some patches) to Boost.Date_Time, Boost.Asio, and Boost.System to the Boost Trac installation. I've listed them down here with a short description of what the issue is and what the solution is (and where you can get the patch for Boost 1.36.0). GCC 4.3.2 and stricter identifier restrictions In the past versions of GCC, the following code would pose no problems: namespace ns { template <class T> struct name { }; name<int> name; // error here! } Now however, you'll get an error saying "declaration of 'name' changes the meaning of identifier 'name'". Apparently the fix is trivial which is to give the namespace qualified name: namespace ns { template <class T> struct name { }; ns::name<int> name; // no error anymore } There is some code in Boost.Date_Time (release 1.36.0) which has this problem. The issue is reported as Boost Trac issue #2465. GCC 4.3.2 and stricter member construction requirements Apparently GCC 4.3.2 has a more strict requirement on when a particular member variable is actually initialized or not -- especially when they are used as temporaries in a static function. I'm not sure if this is a compiler bug/feature, but nonetheless Boost.Date_Time's contrained_value template does not explicitly initialize the member 'value_' variable. The trivial fix (which is to default-construct the member variable in the constructor) is available attached to issue #2463. Boost.System's Missing 'get_posix_category' In Boost 1.36.0, Boost.System's get_posix_category function had been removed. For strict backwards compatibility, it has to be put in to let older versions of libraries that use the function to link properly. This has been submitted as issue (with patches attached) #2461. Boost.Asio's 'pipe_select_interrupter' warning Still with GCC 4.3.2, discarded return values turn out to be warned against. There is a function in Boost.Asio's detail implementations that calls '::write(...)' and then ignores the return value -- which throws a warning and causes builds with -Werror to fail. The trivial patch is attached to the submitted issue #2462. Caveats These patches are submitted to the Boost community through the Trac Issue Trackings system. They have not yet been accepted by authors/maintainers at the time of this writing. Like the saying goes, use at your own risk. Just as a reminder, these patches are to be applied to the Boost 1.36.0 release -- Boost 1.37.0 may have some of these issues addressed. If you find have questions about the patches (and don't want to post comments to the blog entry) please contact me directly through dean.berris(a)cplusplus-soup.com. -- Posted By Dean Michael to C++ Soup! at 11/03/2008 05:27:00 AM ---->8--- -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

1 0

[timer_scheduler] is there any interest on a timer scheduler library?
by vicente.botet 03 Nov '08

03 Nov '08

Hi, I would like to be able to submit/schedule tasks at a given time (callouts) which could be oneshot or periodics. Something like the_timer_scheduler::schedule_at(t1_, now()+seconds(10)); Is there any interest on this feature? I have started to scketch the interface of the library. Note: I have used timeout because timer already exists in the boost namespace. callout could be also used if this is more clear. Note. This interface do not allow arbitrary callbacks functions. struct timeout; typedef void (*timeout_callback)(timeout&); struct timeout_type { timeout_type(timeout_callback callback); timeout_callback operator()(timeout&); }; struct timeout { timeout(const timeout_type& type); const timeout_type& type; // ... }; // template class that store in addition a context template <typename CTX, timeout_type& TYPE> struct timeout_ctx : timeout { timeout_ctx(CTX* ctx) : timeout(TYPE) , context_(ctx) {} CTX* context() {return context_;} CTX* operator CTX*() {return context_;} protected: CTX* context_; }; // there is a single timer scheduler namespace the_timer_scheduler { void schedule_at(timeout& handle, system_time& absolute_time); void reschedule_at(timeout& handle, system_time& absolute_time); void schedule_at_periodicaly(timeout& handle, system_time& absolute_time, duration_type period); void reschedule_at_periodicaly(timeout& handle, system_time& absolute_time, duration_type period); void cancel(timeout& handle); } Example: static const timeout_type t1_type; struct my_ctx, typedef timeout_ctx<my_ctx, t1_type> t1; struct my_ctx { my_ctx() : t1_(this) {} t1 t1_; void on_t1(); static void on_t1(timer* p) { static_cast<t1*>(p)->context()->on_t1(); } void funct() { the_timer_scheduler::schedule_at(t1_, now()+seconds(10)); // ... the_timer_scheduler::cancel(t1_); } }; timeout_type t1_type(ctx::on_t1); The implementation of the timeouts scheduler could be based on "Redesigning the BSD Callout and Timer Facilities" by Adam M. Costello, George Varghese http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B5202FC949FF3EDB0E… Vicente

2 2

[threads] adopt_lock_t question
by Jens Finkhäuser 03 Nov '08

03 Nov '08

Hi! I've come across something that puzzles me. I've got code that, condensed to relevant parts, looks like this: recursive_mutex m; lock_guard<recursive_mutex> l1(m); lock_guard<recursive_mutex> l2(m, adopt_lock_t()); What happens is that if -DNDEBUG is set, the code passes. But if -DDEBUG is set, l1's destructor aborts. Further investigation shows that the destructor calls the mutexe's unlock() function (as expected), which in turn tries to unlock it's internal mutex object - in my case a pthread mutex. The difference between the compilation modes is that the return value of that unlocking function is wrapped in a BOOST_VERIFY(), i.e. assert() call. As I understand the documentation, my code is perfectly valid. It may not make a large amount of sense to use adopt_lock_t as the nature of recursive_mutex should be to not block in l2's constructor - but that's a different matter. Now according to the documentation, lock_guard expects a Lockable, recursive_mutex is a Lockable, and Lockable's unlock() specifies very clearly what sort of conditions need to be met for the function to work: Precondition: The current thread owns *this. Effects: Releases ownership by the current thread. Postcondition: The current thread no longer owns *this. Throws: Nothing So there you have it, in my case the current thread does not own *this after l2's destructor ran - in fact, no thread does. Now there are a two inconsistencies here: 1. The code works fine with other Lockable implementations, such as non-recursive boost mutexes. 2. The behaviour is different depending on compilation mode. Yes, that's the idea behind asserts, but parts of the documentation suggest one behaviour is to be expected, other parts suggest the other is. From that I must draw the conclusion that either recursive_mutex and the unlock() documentation is broken, or the non-recursive mutexes are. Now conceptually, I'd expect unlock() to always succeed. That is, if it's postcondition can be fulfilled, it should always, regardless of compilation mode, exit cleanly. In that case the precondition docs should read something like "*this is either owned by the current thread, or by no thread at all.". I find that to be the case especially for recursive mutexes, as they're intended to be locked/unlocked multiple times in the same thread (though, technically, the calls should always be balanced). All of this is with version 1.35.0, but the docs for 1.36.0 don't seem to be different in the relevant areas. Maybe I'm missing something vital here. If so, I'd greatly appreciate any insight you guys might have. (Incidentally, I find it very hard to disable BOOST_VERIFY with a BOOST_DISABLE_ASSERTS define. I'll have to dig deeper where the re-enabling of asserts sneaks in, but on some machines that has no effect, on others it solves my particular problem, regardless of how correct or incorrect it might be.) Thanks, Jens

2 4

new libaray Boost.Fiber in vault
by k-oli＠gmx.de 03 Nov '08

03 Nov '08

Hello, I've added Boost.Fiber to the boost vault. The library implements lightweight threads of execution (context swapping; fibers on Windows). regards, Oliver

5 14

[1.37.0] Release package final QA
by Beman Dawes 03 Nov '08

03 Nov '08

The 1.37.0 release packages are up at http://boost.cowic.de/rc/ There will be a hold of several hours for last minute QA checks before these get pushed out to SourceForge. In the meantime, if anyone spots any showstoppers, please let us know right away! Thanks, --Beman

3 3

[MultiIndex] "Compatible Sorting Criterion"
by David Abrahams 02 Nov '08

02 Nov '08

The docs mention that the definition is cumbersome. I think you could probably do much better with a formulation that relies on the concept of being partitioned with respect to a predicate function. See www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1313.html and the wording changes (now in the standard) at: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#270 -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 2

Negative Cycle Detection Code
by Paul De La Musica 02 Nov '08

02 Nov '08

Hi, Is there any negative cycle detection code in the public domain? We would prefer BGL based code but LEDA is fine too. Thanks, Paul

2 1

[type-traits] virtual function type trait check
by Chris 02 Nov '08

02 Nov '08

I was wondering if it were possible to make a is_virtual_function type trait check. Example: class B { public: virtual void complicatedFunction() { } }; class D : public B { public: void complicatedFnction() { static_assert(**check if D::complicatedFnction() is virtual **); // notice the misspelling. } };

2 2

Building software with Boost
by Lasse Kärkkäinen 01 Nov '08

01 Nov '08

Hi, There are two questions for which I have found no answers: 1. When exactly are -mt (multithreaded) versions of the libraries needed? 2. Boost.System was added in 1.35 and apparently some of the old libraries also depend on it in new Boost versions. Are the inter-library dependencies of Boost actually documented somewhere, or does one need to guess? I need this information in order to write a new FindBoost script for CMake.

5 4

Boost.Build doc changes
by Vladimir Prus 01 Nov '08

01 Nov '08

FYI, I've committed, and then merged to release branch, the following doc changes: 1. https://svn.boost.org/trac/boost/changeset/49508, which makes Jamroot list some of the properties that user might want to specify. 2. https://svn.boost.org/trac/boost/changeset/49511, which revises the Boost.Build docs on configuration and invocation. The problem with the previous docs was that the information a newbie user (of C++ Boost, or of any other project) would have to look at a bunch of pages to understand everything -- e.g. command line syntax was split into two pages, and there was huge unlinked list of features on yet another page. Now, the "Configuration" and "Invocation" sections are supposed to say mostly everything needed for a quickstart. I also though that getting started needs update, to link to those pages, and to use toolset= as opposed to --toolset=, but it does not seem like there's time for that. - Volodya -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2

1 0