- Boost - lists.boost.org

[data_time] conversion warnings on 64bit platform
by Christopher Lux 28 Oct '08

28 Oct '08

Hi, when using date_time on a 64bit windows platform i get a warning that a int64 value is converted to a long value in the following section: boost/date_time/time_system_split.hpp 189 typename date_duration_type::duration_rep_type doff = day_offset.add(td.ticks()); I use date_time with the BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG macro set to get nanosec timer abilities (my own timers over the boost interface). Is this warning serious or can it be neglected? Regards -chris -- Christopher Lux | | Bauhaus-Universität Weimar | faculty of media - virtual reality systems group

1 0

[1.37.0 beta] Beta release available on SourceForge
by Beman Dawes 28 Oct '08

28 Oct '08

1.37.0 beta 1 is available on SourceForge. See http://tinyurl.com/674rcl There is one known bug in the beta; the Getting Started Guide release number is still shown as 1.36.0. That will be fixed in the final release. There is one new library (Proto) in the release and numerous bug fixes and updates to existing libraries. The beta period will be approximately ten days. Please post bug reports to either the boost developer or user lists, but also let us hear about success stories too! Many thanks to Eric Niebler, Daniel James, Rene Rivera, Marshall Clow, the testers, and all the others who helped to get this beta release together. --Beman Dawes

9 17

[Asio] Match condition based on asio::streambuf length
by Chet S 27 Oct '08

27 Oct '08

Hello, I'm attempting to write a TCP-based server that can interpret a protocol that has a prepended length followed by variable length data. To do this, I'm using async_read_until along with an asio::streambuf. In order to ensure that there is enough data in the buffer for my next async read handler in the chain, I've written a match condition that will return true if there is enough data already in the streambuf to satisfy the read: class read_until_length { public: explicit read_until_length(size_t len) : m_len(len) { } template<typename Iterator> std::pair<Iterator, bool> operator()(Iterator begin, Iterator end) const { Iterator i = begin; const size_t buffer_len = std::distance(begin,end); if(buffer_len >= m_len) { std::advance(i, m_len); return std::make_pair(i, true); } else return std::make_pair(end, false); } private: size_t m_len; }; And then I use it in chained calls to async_read_until as such: Connection::start() { // Call our next handler when we have received at least 4 bytes (which represents the payload length that will follow) boost::async_read_until(m_socket, // boost::asio::ip::tcp::socket m_data, // boost::asio::streambuf read_until_length(4), boost::bind(&Connection::read_element, this, boost::asio::placeholders::error)); } Connection::read_length(boost::system::error_code& error) { // Read out the 4 byte size header size_t length = 0; memcpy(&length, &*boost::asio::buffers_begin(m_data.data()), sizeof(size_t)); m_data.consume(sizeof(size_t)); // Read out the variable length data next now that we know the size of it boost::asio::async_read_until(m_socket, m_data, read_until_length(length), boost::bind(&Connection::read_data this, length, boost::asio::placeholders::error)); } Connection::read_data(size_t length, boost::system::error_code& error) { // Consume the payload of length bytes... } The problem that I'm having is that async_read_until() performs two checks on the match condition. The first (boost/asio/impl/read_until.ipp:954) is to see if the iterator returned from the match condition is at the end of the buffer. If that is true, it does not post the next handler and assumes that not enough data has been read from the socket. This causes a problem when there is exactly enough data in the streambuf with the match condition as written above. It seems that returning true from the match condition (in the second part of the std::pair<>) should still post a handler since the condition was matched and it shouldn't be overridden by the iterator being at the end of the buffer. Is there a way to use async_read_until and a custom match condition to match the exact size of the streambuf? Thanks in advance. --Chet

1 0

Using allocator rebind on an incomplete type
by Chris Newbold 27 Oct '08

27 Oct '08

In trying to clean up some code in Boost.Pool, I've run afoul of some code in Microsoft's implementation of the STL where they are using allocator::rebind on an incomplete type. Something like this: struct Node; // Incomplete! template<typename T, typename Alloc> struct List { Alloc<T>::rebind<Node>::other::pointer node_p; ... } I believe that attempting to instantiate an allocator with an incomplete type is illegal so, by extension, I would have assumed that attempting to rebind on an incomplete type would also be illegal, no? -Chris

3 6

[threadpool] version 11 - some code cleanup
by k-oli＠gmx.de 27 Oct '08

27 Oct '08

Hello, I've uplaoded v11 to boost vault /concurrent programming. - documentation now in quickbook format, some enhancements - examples with Jam file - test with mJam file - code cleanup - API cleanup regards, Oliver

1 0

[test] linking does not return
by k-oli＠gmx.de 27 Oct '08

27 Oct '08

Hello, I've some test files but the link-step does not return (waits forever). gcc.link ../../../bin.v2/libs/tp/test/test_bounded_queue_fifo.test/gcc-4.3.1/debug/link-static/threading-multi/test_bounded_queue_fifo The Jam file: import testing ; project : requirements <library>../../test/build//boost_unit_test_framework <library>../../thread/build//boost_thread <library>../../system/build//boost_system <link>static <threading>multi ; rule tp-test ( source ) { return [ run $(source).cpp ] ; } test-suite thread_pool : [ tp-test test_bounded_queue_fifo ] [ tp-test test_bounded_queue_lifo ] [ tp-test test_bounded_queue_priority ] [ tp-test test_bounded_queue_smart ] [ tp-test test_unbounded_queue_fifo ] [ tp-test test_unbounded_queue_lifo ] [ tp-test test_unbounded_queue_priority ] [ tp-test test_unbounded_queue_smart ] ; Platform LINUX (Debian/Lenny). regards, Oliver

3 3

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