- Boost - lists.boost.org

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

Boost.Build merge?
by Vladimir Prus 16 Oct '08

16 Oct '08

Folks, I would have like to merge Boost.Build state from trunk to release branch. This matter was discussed briefly in http://thread.gmane.org/gmane.comp.lib.boost.devel/180814/ but it didi not lead anywhere, and further it seems to be some confusion between merging Boost.Jam (which Rene wants) and merging Boost.Build. To reiterate, I think Boost.Build should be merged because: - it now supports linux->windows cross compile - it allows to eliminate configuration warning messages from libraries that are not built (which requires corresponding merges for libraries Jamfiles, but it's trivial) - it fixes a bug where include=/foo/bar could not be specified on the command line - it has some other smaller fixes - I don't see any breakage on trunk tests Comments? - Volodya -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2

7 17