- Boost - lists.boost.org

[threadpool] bugfix release
by k-oli＠gmx.de 11 Oct '08

11 Oct '08

Hello, I've released a new version of threadpool - it fiexes the broken pool::shutdown_now() and resets the scann counterin work_stealing after sleep or channel::take(). regards, Oliver

1 0

boost::program_options question - enabling multiple usage of the same switch
by Khaikin, Sergey 11 Oct '08

11 Oct '08

Hi, This question was originally brought up here: http://lists.boost.org/boost-users/2006/08/21633.php but unfortunately was not answered. What I basically want to do is to enable something like running $ myprog -v -v -v Where -v is some Boolean switch. Thanks, -Sergey --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 2

Re: [boost] [Review] Phoenix review results
by dan marsden 11 Oct '08

11 Oct '08

Joel de Guzman wrote: >Eric Niebler wrote: >> >> Joel de Guzman wrote: >>> Now it's time to grab a beer and celebrate :-) >> >> And to get (back) to work on Phoenix v3! ;-) Congrats. > >Part of Phoenix' success is due to the easy extension mechanism. >It would be super awesome if you can find some ways to simplify >V3 extension to something as easy as V2's. I intend to apply >whatever technique you can come up with to Spirit2. Yeah, I'm >not happy with its extension mechanism too. Nevertheless, I >am starting a Spirit 2.1 using Phoenix V3 as the model. I think the problem with the v2 extension mechanism is that we exposed how the expression templates were implemented. That left us with no choice but to make a breaking change in the extension mechanism between v2 and v3. IMO ideally any extension mechanism for v3 would not expose directly that proto is the underlying ET engine. I'm not sure how practical this will be to do though, as we may need a mass of indirection to avoid exposing proto directly? Cheers Dan

1 0

Re: [boost] [Review] Phoenix review results
by Eric Niebler 11 Oct '08

11 Oct '08

Joel de Guzman wrote: > Now it's time to grab a beer and celebrate :-) And to get (back) to work on Phoenix v3! ;-) Congrats. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[1.37.0][Test] Release branch Boost.Test failures?
by Beman Dawes 11 Oct '08

11 Oct '08

Boost.Test continues to fail ifstream_line_iterator_test on all platforms except Windows. http://beta.boost.org/development/tests/release/developer/test.html What's up? When will this be fixed or marked up as an expected failure? --Beman Running 2 test cases... ../libs/test/test/ifstream_line_iterator_test.cpp(35): error in "test_default_delimeter": check *it == "acv ffg" failed [acv ffg != acv ffg] ../libs/test/test/ifstream_line_iterator_test.cpp(38): error in "test_default_delimeter": check *it == "" failed [ != ] ../libs/test/test/ifstream_line_iterator_test.cpp(41): error in "test_default_delimeter": check *it == " " failed [ != ] ../libs/test/test/ifstream_line_iterator_test.cpp(63): error in "test_custom_delimeter": check *it == "\n{ d \n dsfg\n" failed [ { d dsfg != { d dsfg ] ../libs/test/test/ifstream_line_iterator_test.cpp(66): error in "test_custom_delimeter": check *it == "\n" failed [ != ] *** 5 failures detected in test suite "Master Test Suite"

2 2

Coroutines and Output Iterators
by Mathias Gaunard 11 Oct '08

11 Oct '08

When one wants to generate some range of data, the usual approach is to write the data to some output iterator passed as an argument. However, that approach has a few drawbacks: it is necessary to provide a range (often of a non-known size) to write the data on, and it will be possible to consider that data only once all elements have been copied to the output. An alternative approach is returning a smart range which will generate the elements as it is being iterated. It is somewhat what the Boost.Range update in the review queue does. This approach has many advantages, since storage may not be needed and transformations can be combined on top, avoiding unnecessary iterations. Writing smart iterators/ranges that generate data, though, is much more difficult than writing generators using the previous solution, especially in recursive scenarios where the iterators will need to maintain a stack themselves. Another solution is coroutines, which allows to return data then reenter later in the same context and keep going. The results of a coroutine can then be iterated as they come, giving the advantages of smart iterator/ranges while keeping the syntax of output iterators. It is however at the cost of some stack allocation at the beginning (which can be improved using pools) and context switches at each iteration. What I propose is thus to make an output iterator that will yield the data within a coroutine context. With that solution, one writes generators as functions writing to output iterators, but those iterators might as well be writing to containers than actually yielding the result, which means the person designing the generator does not have the overhead of coroutines forced upon him. The syntax would be generate(boost::bind(&boost::transform, range, _1, f)) which would return a range similar to that of boost::make_transform_range(range, f). (boost::transform being just std::transform for ranges) The coroutine GSoC library from 2006 does offer that kind of thing, but not as non-intrusive output iterators. (I don't even get why it needs to call self.__self_exit__() at the end). I thus propose a simple output iterator that yields on iteration be made. By the way, what is the status of that library? I haven't heard of it for quite a while.

4 5

[multi_array] Slices, views and sub_arrays
by Robert Jones 10 Oct '08

10 Oct '08

Hi All I'm still plugging away at trying to make use of multi_array, but I seem to be having a few problems! I suspect my understanding of the basic paradigm is flawed. I'm bit confused about views and slices. If I start with a rectangular, 2 dimensional grid, take a view of the whole grid, and then use a single subscript to index into that view, then I expected the result to be a view of one less dimension then the original view. However, it seems to be a "sub_array". #include "boost/multi_array.hpp" struct Cell { int i; }; int main( ) { typedef boost :: multi_array_types :: index_range range; boost :: multi_array< Cell, 2 > grid( boost :: extents[ 9 ][ 9 ] ); boost :: multi_array< Cell, 2 > :: const_array_view< 2 > :: type const_grid_view = grid[ boost :: indices[ range( ) ][ range( ) ] ]; boost :: multi_array< Cell, 2 > :: const_array_view< 1 > :: type const_row_view = const_grid_view[ 5 ]; return 0; } The error message from the last assignment is this sample.cpp: In function `int main()': sample.cpp:13: error: conversion from `boost::detail::multi_array::const_sub_array<Cell, 1u, const Cell*>' to non-scalar type `boost::detail::multi_array::const_multi_array_view<Cell, 1u, const Cell*>' requested which seems to confirm I've got all my consts and dimensions correct. So, why is this wrong? Also, does the return type of sub_array, rather than array_view, mean that the contents of the relevant cells have been copied? Thanks - Rob.

2 1

[website] libs/* --> doc/libs/BOOST_VERSION/libs/* rewriting rule
by joaquin＠tid.es 10 Oct '08

10 Oct '08

Hello, The website PHP is devised in such a way that documentation URLs are automatically rewritten to point to the specific Boost version most recently shipped. For instance, if I type the following in my browser: http://www.boost.org/libs/smart_ptr/smart_ptr.htm I get the following redirection: http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/smart_ptr.htm This is fine in that it allows us to keep a historic record of documentation across Boost versions. My little complain is that the automatic redirection makes it all too easy to inadvertently use version-specific URLs when referring to Boost docs in external contexts (blogs, forums, etc.) This is in my opinion unfortunate because such URLs are stuck in time and do not reflect the evolution of the library. Of course it's easy to get to the most recent info, but untrained eyes might miss the detail and take the version-specific URL for the most updated reference. A simple Google search (http://tinyurl.com/42ufrn ) reveals that these version-specific URLs are beginning to proliferate. Maybe is it a good idea to not apply this redirection and instead serve the most updated docs for non-version-labeled URLs? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Getting the types of arguments for a bind.
by Michael Marcin 10 Oct '08

10 Oct '08

I want to take a boost::bind functor and get the type of its arguments. I can't find any sort of introspection api documented. I tried using mpl but what I came up with doesn't seem to work. Is there a way to do this? A distilled version of my failed attempt follows #include <boost/bind.hpp> #include <boost/mpl/find.hpp> #include <boost/type_traits/function_traits.hpp> template< typename Function, int N > struct arg_n; template< typename Function > struct arg_n< Function, 1 > { typedef typename boost::function_traits< Function >::arg1_type type; }; template< typename Callback, int ArgN > struct arg_type; template< typename Return, typename Signature, typename Args, int ArgN > struct arg_type< boost::_bi::bind_t<Return,Signature,Args>, ArgN > { typedef typename boost::mpl::find< Args, boost::arg<ArgN> >::type iter; // +1 for 0 based find vs 1 based arguments typedef typename arg_n<Signature,iter::pos::value + 1>::type type; }; void foo( int a ) {} template< typename Callback > void bar( Callback cb ) { // trivial usage typedef typename arg_type< Callback, 1 >::type ArgType; cb( ArgType() ); } int main() { bar( boost::bind(&foo,_1) ); } Thanks, -- Michael Marcin

2 1

[shared_ptr] Why operator< uses internal_less?
by dariomt＠gmail.com 10 Oct '08

10 Oct '08

I see that operator== and operator!= are implemented comparing the pointer inside the shared_ptr's using get(), but operator< uses _internal_less, that does a different thing. I thought that operator< would also be implemented using get(), so please, can you share the rationale behind the need for _internal_less? TIA

7 6