October 2008 - Boost - lists.boost.org

Re: [boost] New library in Vault: Msm (Meta State Machine)
by christophe henry 17 Oct '08

17 Oct '08

Hi Andreas, > What do t & D stand for (they do not appear in Figure 2)? They don't seem to be necessary to implement the chart?You should also read the mini doc I included. I added them to make the problem a bit more interesting and show how to solve it with flags. > 1) Is it possible to implement the transitions exactly as shown in the chart? It is not, again as explained in the mini doc. I see this as an UML goto and decided to implement superior tools instead. > 2) If no, is this why you introduced two self-transitions to C, one with a guard to prevent transition from B?I didn't. They were there before, I just made them cleaner by using state flagging and a guard condition instead of crossing state boundaries. The UML diagram of the doc looks, in my opinion, cleaner now, less like spaghetti. Of course I could implement these entry and exit goto-like pseudo states if users want them. I just strongly doubt they are needed. _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

2 1

New library in the Vault: ConstantTimeSize
by vicente.botet 16 Oct '08

16 Oct '08

Hi, Boost.ConstantTimeSize defines a configurable wrapper to the stl container list providing a size function with constant, linear or quasy_constant complexity. You can find the sources, documentation and some test in the Boost Vault. http://www.boostpro.com/vault/index.php?action=downloadfile&filename=consta… Any comments are wellcome, Vicente

8 17

[thread_safe_signals][signals2] call for reviewers (review tentatively scheduled Nov 1st - Nov 10th)
by Stjepan Rajko 16 Oct '08

16 Oct '08

Hello all, The review for the Signals2 library (formerly known as thread_safe_signals - description below) submitted by Frank Mori Hess has been tentatively scheduled for Nov 1st - Nov 10th. As per a recent discussion on the review process (http://tinyurl.com/48tdjs) and after consulting with the review wizards, we would like to try something new for this review: have a number of reviewers commit beforehand to submitting a review. The goal of signing up is to ensure that there is both sufficient interest in the library, and that there will be enough reviews submitted for an informed decision on acceptance. If you are interested in this library, I encourage you to sign up now to be a reviewer (by this you commit to submitting a review preferably by the end of the review period). Of course, additional reviews from non-signed-up reviewers will also be welcome, but without enough reviewers signing up beforehand it is not clear that we should proceed with a review at this time. To sign up, please send me a reply (here or privately), and let me know whether the review period is suitable for you (we can make some adjustments if necessary). I strongly encourage participation from reviewers that would examine the library from a purely user standpoint (commenting on the interface and / or the documentation), as well as reviewers that would be willing to look into the details of the implementation (i.e., you don't have to focus on both). I you would like to sign up, please let me know by this Saturday (October 18th). About the library: -------- * The library can be downloaded from: http://www.boostpro.com/vault/index.php?&directory=thread_safe_signals (latest version is signals2-2008-10-08.zip) * Documentation is also available online: http://www.comedi.org/projects/signals2/libs/signals2/doc/html/index.html * A synopsis: The Boost.Signals2 library (formerly known as thread_safe_signals) is an implementation of a managed signals and slots system. Signals represent callbacks with multiple targets, and are also called publishers or events in similar systems. Signals are connected to some set of slots, which are callback receivers (also called event targets or subscribers), which are called when the signal is "emitted." Signals and slots are managed, in that signals and slots (or, more properly, objects that occur as part of the slots) can track connections and are capable of automatically disconnecting signal/slot connections when either is destroyed. This enables the user to make signal/slot connections without expending a great effort to manage the lifetimes of those connections with regard to the lifetimes of all objects involved. When signals are connected to multiple slots, there is a question regarding the relationship between the return values of the slots and the return value of the signals. Boost.Signals2 allows the user to specify the manner in which multiple return values are combined. * Relationship to Boost.Signals: This is a thread-safe variant of the original Boost.Signals library. There have been some changes to the interface to support thread-safety, mostly with respect to automatic connection management. The following thread offers some more details on the differences between the two implementations, as well as a plan of a phased replacement of Boost.Signals should Signals2 be accepted: http://tinyurl.com/4sqau3 [nabble] Again, if you are interested in this library, please consider signing up as a reviewer. Kind regards, Stjepan (review manager)

6 12

Build doc update
by Vladimir Prus 16 Oct '08

16 Oct '08

According to: http://www.boost.org/development/index.html we're supposed to have beta release tomorrow, and final release on 31st. Are doc changes allowed in between? What becomes apparent on IRC, is that the current install docs have issues: - Boost.Build command line syntax docs are not very good, because they split information across several pages - Getting started fails to refer to command line syntax directly. - Getting started lists various variants that may be built, and their names, but does not give Boost.Build options to request those variants, so people start to improvise various interesting syntaxes. - It fails to clearly say that 'configure'/'make' is the approach that's only good for native, all-default build. I think it would be good to clear this up, and can work on this, but of course only if the changes can be gotten in. Comments? - Volodya

4 5

[1.37][Function] Request permission to merge changes
by Doug Gregor 16 Oct '08

16 Oct '08

Aleksey pointed out that Boost.Function in 1.36.0 has a critical thread-safety problem. I've now fixed the problem on the trunk, and---after regression tests cycle---would like to merge these changes (along with other long-stable fixes to Function) to the release branch. Okay? - Doug

4 9

boost 1.34.1 -static boost::mutex
by keren A 16 Oct '08

16 Oct '08

Hi. I use boost's function: lock. The code run on windows but in linux I'm stacked on the lock. my code: Code: class A{ void foo() { boost::mutex::scoped_lock lock(m_locker); doSomething();// The code never arrives here in linux. } static boost::mutex m_locker; };

2 1

Re: [boost] New library in Vault: Msm (Meta State Machine)
by christophe henry 16 Oct '08

16 Oct '08

Hi Andreas, I just uploaded the solution to your question into the Vault: http://www.boostpro.com/vault/index.php?direction=0&order=&directory=Msm& Regards, Christophe _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

2 1

Boost house style?
by Robert Jones 16 Oct '08

16 Oct '08

I've been looking at the implementation of Boost.multi_array, and in particular the mechanics of generating the array extents objects. The problem to be solved is to allow the extent of a multi-dimensional array to be specified with this syntax extents[2][3][4] since this forms a nice nmemonic. The solution is a templated type template <unsigned ndims> class extents_type {.....}; which contains a subscripting operator which returns its own object with an extra subscript tacked-on extents_type<ndims+1> operator[]( unsigned n ) {....} OK. That's all fairly straight-forward. The interesting bit is the specialisation required for the initial dimensionless object. The Boost implementation goes through several intermediate objects which eventually resolve to a boost::array<unsigned, ndims> in general, or a boost::array<unsigned, 1> for the dimensionless case. My questions about this are: * why boost::array<unsigned, 1> rather than boost::array<unsigned, 0>? Obviously an array of zero elements is an odd beast, but it seems to work, with begin() equal to end() as you'd expect. * is it necessary to employ so many different objects to resolve the special case? Is this an aspect of the Boost style guidlelines, or simply some C++ good practise that I've missed? The existing implementation of this is in boost/multi_array/range_list.hpp if you're interested. Thanks, Rob.

2 1

Jamroot merge
by Vladimir Prus 16 Oct '08

16 Oct '08

Hi, I would like to merge the following changes of Jamroot to release branch: http://svn.boost.org/trac/boost/changeset/49255/ http://svn.boost.org/trac/boost/changeset/49318/ These make install process actually install TR1 headers. Previously, they were skipped. We had this bug in 1.36, and probably eariler, and in makes TR1 totally broken. OK? - Volodya

3 2

Merge intel-linux build fix?
by Vladimir Prus 16 Oct '08

16 Oct '08

I would like to merge this patch: https://svn.boost.org/trac/boost/changeset/49357 which fixes this ticket: http://svn.boost.org/trac/boost/ticket/2413 which reports that intel-linux fails to add -fPIC, which causes linking to fail on 64-bit systems. The reporter has confirmed that the issue is fixed. OK? - Volodya

3 2