May 2012 - Boost - lists.preview.boost.org

[range] Will Boost.Range be merged
by Barend Gehrels 26 May '12

26 May '12

Hi, Will Boost.Range (including the change of boost::size from signed to unsigned) be merged into release? Regards, Barend

1 0

[python] incorrect use of keywords and, or, etc
by lcaminiti 25 May '12

25 May '12

Hello all, Boost.Python uses operator keywords in macro expansion. This is a bad idea because on some compilers like MSVC that implement and, or, etc using macros #define to &&, ||, these macros will not expand correctly when ciso646 is included before including python.hpp. #include <ciso646> // boost/python/operators.hpp BOOST_PYTHON_BINARY_OPERATOR(and, rand, &) BOOST_PYTHON_BINARY_OPERATOR(or, ror, |) ... This will actually expand to: BOOST_PYTHON_BINARY_OPERATOR(&&, rand, &) BOOST_PYTHON_BINARY_OPERATOR(||, ror, |) And then expand the macro causing a compiler error because the operator code will have names like op_&&, op_||, etc instead of the intended op_and, op_or, etc. An easy and safe fix should be to change the macro to move the _ to the macro call: BOOST_PYTHON_BINARY_OPERATOR(_and, rand, &) BOOST_PYTHON_BINARY_OPERATOR(_or, ror, |) Now _and, _or, etc are no longer keywords so it's safe to use them. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-python-incorrect-use-of-keywords-a… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[range] Boost.Range induced regression, is there somewhere a change?
by Barend Gehrels 25 May '12

25 May '12

Hi, Is there something changed in Boost.Range? Background: I just noticed that there appeared many failing issues (yellow squares) in the Boost.Geometry regression matrix here: http://www.boost.org/development/tests/trunk/developer/geometry.html I checked the assemble square and it gives me an assertion: Assertion `id.ring_index >= -1 && id.ring_index < boost::size(interior_rings(polygon))' Because this did not use to be the case, I did run the test on my local machine and it was OK. Then I updated some Boost libraries (manually, separately) and as soon as I updated Boost.Range this exception did appear. So the regression is somehow caused by a change in Boost.Range. I did not yet research it further, it might be that we do something wrong here that was previously accepted but now is not, but it still stays an unexpected regression... Is there someone who has any idea what introduced this? Thanks, Barend

1 1

C++ Standards Committee membership for Boost?
by Beman Dawes 25 May '12

25 May '12

The relationship between Boost and the C++ Standards Committee has been strictly informal. That's been fine, particularly given that most Boost moderators were members of the standards committee and regularly attended meetings. As the standards committee gears up to accept library proposals, the relationship is getting even closer. I believe it would be advantageous for Boost to join the C++ committee as a voting member. Procedurally, that would mean joining the INCITS (www.incits.org) PL22.16, which is the US national body for C++ standardization. Boost is consider US domiciled in ISO-speak. The advantages of joining include: * We get to participate in formal votes. Right now, we only participate in straw votes. * Boosters would be able to attend committee meetings by right rather than as a courtesy. * Boosters would be able to participate in committee mailing lists with less hoops to jump through. * Psychologically, it may give us a bit more weight in committee matters. Comments? Opinions? --Beman

8 14

regression tests fail with no error?
by lcaminiti 24 May '12

24 May '12

Hello all, Some of my library regression tests occasionally fail like this: http://www.boost.org/development/tests/release/developer/Sandia-darwin-inte… If you follow the link, there is no actual error. Plus the tests sometimes it fails (with no actual error) and other times it passes (as it should). Is this just a problem with the regression test parsing script? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-regression-tests-fail-with-no-erro… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[1.50.0] Beta schedule
by Beman Dawes 24 May '12

24 May '12

C++Now! is history, so it is high time to get the 1.50.0 beta out the door. Branches/release is now closed for all changes except by permission from a release manager. Unless there are strong objections, I suggest we close branches\release for all changes next Monday, May 28, and ship the beta release as soon after that as a RC can be built and tested. I'm about to post a separate message discussing the length of beta periods. --Beman

19 51

[MSM] Single event, multiple orthogonal submachines
by Andrew Hundt 23 May '12

23 May '12

I'm trying to deal with having multiple orthogonal submachines that process one event containing data. I have a contrived example that hopefully conveys the issue. Suppose I am hoping to create a state machine "Game2D" with a set of orthogonal submachines that guard certain transitions based on each other, and I would like some events to be processed by multiple submachines. Parent Machine: Game2D Event: CharacterStatus - contains character position and velocity Submachines: IsMoving - changes state based on CharacterStatus CorrectPosition - updates position based on CharacterStatus CharacterStatusUpToDate - times out to an error state if CharacterStatus hasn't been received for a while EnemyAlive - doesn't process CharacterStatus RunSystem - guards some transitions based on the state of IsMoving Since some, but not all of these submachines needs the "CharacterStatus" event, what is the best way to make sure they all get it when I call Game2D.process_event(CharacterStatus)? I want to be able to reuse these pieces, and keep things as simple as possible. Does this seem like an ok approach? Should I simply have a state "UpdateCharacterStatus" that directly updates each of these objects then creates an event to transition away, or something else entirely? Cheers! Andrew Hundt

2 1

Release schedule related updates
by Beman Dawes 23 May '12

23 May '12

https://svn.boost.org/trac/boost/wiki/ReleaseSchedule has been updated to reflect experience and lengthen the beta period. https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList has been updated to reflect the importance of the calendar. The Google calendar itself has been updated for releases 1.50.0, 1.51.0, and 1.52.0. I'm looking into ways to queue postings of release milestones so they get sent automatically and don't get forgotten. Thanks, --Beman

1 0

[ot] choosing a build system
by Nathan Ridge 23 May '12

23 May '12

Hello, I am developing a new C++ library (unrelated to Boost) and I need to choose a build system for it. I had originally planned to use Boost.Build, because I figured that it would be particularly suitable for a C++ library, and because I've come to associate Boost with high quality and excellence. However, recently I've heard talk of Boost switching its own build system from Boost.Build to CMake (in fact, the currently active thread about modularization suggests that this change is imminent). My understanding is that Boost is the primary user of Boost.Build, and therefore I am concerned about what this switch means for the future of Boost.Build. Do you think choosing Boost.Build as the build system for a project is still a sound choice, or am I better off choosing something else like CMake? More generally, what build system would you recommend for a C++ library? My requirements for the build system are the following: - straightforward support for multiple variants of the build (32-bit vs. 64-bit, debug vs. release, static vs. shared, etc.), including coexistence of multiple variants on the same machine - general ease of use (for the library writer and library users) - suitability for a C++ project - cross-platform, FOSS Any thoughts are appreciated. Thanks, Nate

26 59

spirit classic modularization
by Dave Abrahams 22 May '12

22 May '12

While I was in Aspen I split Spirit and Spirit Classic into separate Git repositories: https://github.com/boost-lib/spirit https://github.com/boost-lib/spirit_classic The manifest entries begin here, and as you can see, are quite long for these two libraries: https://github.com/ryppl/boost-modularize/blob/master/manifest.txt#L643 This is mostly due to the limited expressivity of the manifest language, but regardless... The question, for Spirit developers: which arrangement is better? Should both spirits go back into a single repository? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 4