- Boost - lists.boost.org

Preview 3 of the Geometry Library
by Barend Gehrels 27 Oct '08

27 Oct '08

Dear list, Herewith the URL to the third preview of our Geometry Library, including documentation and examples. The first two previews were sent to this list in January and in March. Since then, Bruno Lalande, already a Boost contributor, joined and we together reworked the library and its concepts. Lines (sequences of points) are now generic, handled using iterator pairs. Concepts have been worked out and integrated everywhere in the code. A Google Summer of Code project, handling Spatial Indexing, is based on the geometries of this library. Many discussions and comments were related to the concepts and, more specific, to the Point concept. This is the most basic thing of a geometry library and has to be as generic as possible. We think we implemented it like that into the library. The library can handle all point types including legacy point types, point types provided by the library, user defined point types, Cartesian points, native arrays, points with spherical coordinates. The library provides point_xy for Cartesian systems and point_ll for lat long systems, but the library user is thus not confined to those types. Using a strategy mechanism, the library should be able to handle every point type, and lines made of those types. The distance / simplify algorithms clearly show this design. The library is not completed, it is still a preview. It is used in real life projects but will still be enhanced and extended. The point type is now generic and lines (sequences of points) are generic. However, boxes, circles and polygons still have to be reviewed and their concepts can be worked out further. Some algorithms will be reprocessed to use strategies and handle any point type. The URL with documentation is here: http://geometrylibrary.geodan.nl. The library is Open Source and uses the Boost License. However, being a preview and not yet a real submission, the SVN is not at boost but still hosted at Geodan. If you are interested you can get SVN access. There were since March two other geometry library references sent to the list. This really shows the need for a Geometry Library into the boost collection. We welcome any discussion, comment or contribution and we are open for any type of cooperation, merge or join. Barend Gehrels

13 49

[zip_iterator] Understanding why.
by Robert Jones 27 Oct '08

27 Oct '08

Zip iterator implements the functionality I need to advance associated iterators through different ranges, but it seems strangly awkward to use, which is odd for Boost. so I'm wondering if I've misunderstood the design paradigms. Given two ranges (say vectors), I'd like to be able to generate an iterable composite, anditerate through that, something like vector<int> v1; vector<int> v2; typedef zip_composite<int, int> Z; Z zip( v1, v2 ); for ( Z::iterator i=zip.begin( ); i !=zip.end( ); ++i ) { // ... blah, blah, blah } Is this impossible or undesirable to implement for reasons I've not realized? Thanks, Rob.

4 3

[1.37.0] Release branch post-beta merges
by Beman Dawes 27 Oct '08

27 Oct '08

The release branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See http://svn.boost.org/trac/boost/wiki/ReleasePractices/PostBetaMerges The final release is currently planned for Sunday, November 2nd. It would be helpful if all merges were complete a couple of days before that to allow plenty of time for tests to cycle and other pre-release preparation. Thanks, --The release managers

1 0

[release management] Draft policy for changes between beta and release
by Beman Dawes 27 Oct '08

27 Oct '08

In another post, John Maddock asked what sort of QA problems should be fixed between the beta and final releases, and what the criteria and procedures are. Here is a quick draft of a possible policy: * Showstoppers. Criteria: Bugs or other problems so serious that the release is seriously compromised if not fixed. Procedure: After discussion on the developers list, release managers will specify how the problem is to be attacked, and what effect it will have on schedule. * Documentation and other minor fixes not affecting code. Criteria: Changes not requiring regression testing and unlikely to impact other libraries. Procedure: Merges to branches/release are OK, after fix applied to trunk, and do not require a release manager's permission. * Minor code fixes. Criteria: Changes believed to have limited risk and that have already been made to trunk and are stable on trunk regression testing. Procedure: Merges to branches/release after fix stable on trunk tests do not require a release manager's permission. * Questionable code fixes. Criteria: Any code changes not meeting the "Minor code fix" criteria, such as a change with a lot of possible ripple effect on other libraries. Procedure: Ask release managers for permission. * Tools changes and fixes. Code changes to bjam, Boost.Build, Boost.Test, the doc build process, and other tools are discouraged late in release cycles in general and between beta and release in particular. Ask release managers for permission if you really think the change is warranted for this release. * New features, breaking changes, major reworks, new libraries. These are not suitable for merging between beta and release. Wait until the next release. Comments? --Beman

5 8

[1.37] status/Jamfile.v2
by Nicola Musatti 27 Oct '08

27 Oct '08

Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago, and it doesn't include the tests for several libraries. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

9 17

[mpl] Error in map docs (or bug)
by John Bytheway 26 Oct '08

26 Oct '08

I think I've found an error in the MPL docs (In trunk and 1.35, and presumably everything in between). The documentation for mpl::map state that "count<m,k>::type" yields "The number of elements with the key k in m", where in fact what it returns is the number of elements *equal* to k in m. This is consistent with the documentation of mpl::count. I suspect this is an error in the docs rather than a bug, since there is also mpl::has_key, which serves the purpose count claims to be serving (but isn't). Consider this code: #include <boost/mpl/has_key.hpp> #include <boost/mpl/count.hpp> #include <boost/mpl/assert.hpp> #include <boost/mpl/set.hpp> #include <boost/mpl/map.hpp> #include <boost/mpl/insert.hpp> using namespace boost::mpl; typedef set< int >::type my_set; typedef map< boost::mpl::pair<int, int> >::type my_map; BOOST_MPL_ASSERT((has_key<my_set, int >::type)); BOOST_MPL_ASSERT((count<my_set, int >::type)); BOOST_MPL_ASSERT((has_key<my_map, int >::type)); BOOST_MPL_ASSERT((count<my_map, int >::type)); BOOST_MPL_ASSERT((count<my_map, pair<int,int> >::type)); The fourth assertion fails. If the map docs were accurate then it would be the fifth assertion that failed. The same error is in the Associative Sequence docs, and perhaps other places. John Bytheway

1 0

Directory monitor for Windows (Boost.Asio extension)
by Boris 26 Oct '08

26 Oct '08

I had created a file monitor in March as a reference implementation of how to develop a Boost.Asio extension. While it was pretty incomplete at that time it has become a grown-up and fully tested directory monitor which supports both synchronous and asynchronous I/O. It currently works on Windows only as it is based on Microsoft's I/O Completion Ports (for those who need a directory monitor on Linux see http://article.gmane.org/gmane.comp.lib.boost.asio.user/2699) The directory monitor can be downloaded here: http://www.highscore.de/boost/dir_monitor.zip The zip archive contains various tests which can be used for a quick start. As the directory monitor is pretty small it shouldn't take much longer than 10 minutes to use it in your own projects. Boris

1 0

[test] Patch for gcc warning suppression.
by John Maddock 25 Oct '08

25 Oct '08

I'm getting a bunch of warnings from floating_point_comparison.hpp with gcc, the attached patch fixes these, if these are OK, I can commit from here. That just leaves: c:\data\boost\boost\trunk/boost/test/floating_point_comparison.hpp:246: warning: 'boost::test_tools::<unnamed>::check_is_small' defined but not used Is there any way to get rid of that as well? Thanks, John.

3 3

Welcome to the Boost Developers Archive on Google Groups!
by Eric Niebler 24 Oct '08

24 Oct '08

I've subscribed Google Groups to the boost developers list, so that people who would like to follow the group that way (and get an RSS feed to the list) can do so. http://groups.google.com/group/boost-developers-archive It can't import old messages, but new messages should show up there and be search-able. I hope. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

Class-level instrospection
by Joel Falcou 24 Oct '08

24 Oct '08

Daniel Walker a écrit : > Why don't we both package what we have, upload to vault, and then > work out merging the two and adding the rest in another thread? I've cleaned-up my files and 'boostified' them so to speak. I've uploaded a 'introspection.zip' on the vault so you can grab it and we can start discussing this in a proper topic ;) Basically i've uploaded the following : BOOST_HAVE_MEMBER_FUNCTION BOOST_HAVE_CONST_MEMBER_FUNCTION BOOST_HAVE_NON_CONST_MEMBER_FUNCTION BOOST_HAVE_MEMBER_DATA Basically, the usage is really simple. You want to check if classes provides a bool is_ok(long) method and you want to catch both const and non-const variations : BOOST_HAVE_MEMBER_FUNCTION(is_ok, bool(long) ) then the check itself is done via : has_member_function<T>::type For BOOST_HAVE_DATA_MEMBER, my method can only check for public members. So I added a macoer called BOOST_INSTROSPECTION_SUPPORT(C,V) that have to be used in user-defined class C that want to publish a member named V to our introspection mecanism. struct foo { private : int mValue; }; struct bar { BOOST_INTROSPECTION_SUPPORT(bar,mValue); private : int mValue; }; BOOST_HAVE_MEMBER_DATA(int, mValue) has_member_data_mValue<foo>::value is false has_member_data_mValue<bar>::value is true Other limitations is that currently you can't have various check for a method with a given name but different signature. I'm working on a fix using PP sequence and : BOOST_HAS_MEMBER_FUNCTION_OVERLOADS(func,(void())(void(int))(void(int,int))) In the same way, checking for suff like operator[] yields invalid class name has_member_function_operator[]. So I propose we hand-code the following : BOOST_HAS_SUBSCRIPT_OPERATOR( void(int) ) that builds a has_subscript_operator<T> class. Other similar operator should be handled the same way.

4 7