- Boost - lists.boost.org

[1.37.0] beta 1 release candidate QA
by Beman Dawes 29 Oct '08

29 Oct '08

1.37.0 beta 1 release candidates are available at http://boost.cowic.de/rc/ Before pushing these out to SourceForge, we need volunteers to download and install, following the getting started guide. See http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html Please report whether the getting started procedure works, and whether the resulting install looks OK. Thanks, --Beman PS: I've added a "five weeks before release" milestone to http://svn.boost.org/trac/boost/wiki/ReleaseSchedule, so that in the future more of these basic QA tasks get done well before the last minute.

4 10

[BGL] bundled properties and their restrictions (particularly default constructibility).
by Geoff Hilton 29 Oct '08

29 Oct '08

Hi, my graph uses bundled properties for both vertices and edges. Both bundled properties have containers that must be of a certain size when they're actually used. For testing purposes these containers were of fixed size (underlying container is currently a boost::array<..>. However the real world dictates that the size of these containers pretty much must be determined at run-time as opposed to compile-time because the graph is built using an external source such as a file or database for example. I know the documentation requires that bundled properties be all of default constructible, assignable and copy constructible[1][2] because of how the containers (as specified by selectors) store them. I'm unsure as to whether or how this may effect algorithms provided by the BGL, so far the only ones I've used are dijkstra_shortest_path and dag_shortest_path. Given that a custom container selector may be created and push/erase must be overloaded for the given custom container (for my purposes, this would be to specify a custom allocator as in the example)[3], how safe would it be to say that the container selector entirely dictates the restrictions in question? If the answer is "very", presuming we weren't to change these restrictions for existing provided selectors would it be possible for an explicit exception to be made for custom containers and their selectors (created using boost::container_gen<>)? This exception might say that the restrictions in question are then dictated by the custom container. I figure this shouldn't affect existing user code since the current restrictions are already at their most strict. Thanks very much, Geoff [1] http://www.boost.org/doc/libs/1_36_0/libs/graph/doc/using_adjacency_list.ht… [2] Doug Gregor 23/03/2005, this list. [3] http://www.boost.org/doc/libs/1_36_0/libs/graph/doc/using_adjacency_list.ht…

2 4

[threads] missing includes in thread.hpp
by Petr Uzel 29 Oct '08

29 Oct '08

Hi list, is there any reason why boost/thread.hpp #includes everything from boost/thread/*.hpp except condition.hpp and tss.hpp ? Is it a bug ? Thanks, -- Best regards / s pozdravem Petr Uzel, Packages maintainer --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: puzel(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 964 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz

1 0

[ASIO/System] Checking error_code
by Carlo Medas 29 Oct '08

29 Oct '08

Dears, sorry for disturbing with peraphs stupid question, but I'm really hung: I'm not able to check the error code (boost::system::error_code) for a specific 'End of File' type. When I print it, it's 'End of file', with int value = 2. But how to check it? I tried with something like: if (error.default_error_condition() == boost::system::error_condition(boost::system::errc::XXX)) { ... } But I don't know what to put in the XXX. Br and thanks, \Carlo Medas

2 2

[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