- Boost - lists.boost.org

disable_if conundrum
by Marshall Clow 05 Dec '11

05 Dec '11

I have a function that returns a pair of iterators. There's also a version that takes a comparison predicate. template<class ForwardIterator, class Compare> std::pair<ForwardIterator, ForwardIterator> foo ( ForwardIterator first, ForwardIterator last ); template<class ForwardIterator, class Compare> std::pair<ForwardIterator, ForwardIterator> foo ( ForwardIterator first, ForwardIterator last, Compare comp ); I want to provide a range-based version of it. template<class Range> std::pair<typename boost::range_iterator<const Range>::type, typename boost::range_iterator<const Range>::type> foo ( const Range &r ); template<class Range, class Compare> std::pair<typename boost::range_iterator<const Range>::type, typename boost::range_iterator<const Range>::type> foo ( const Range &r, Compare comp ); Ok. There's a problem. If I call: foo ( first, last ) I get an error, because there are two perfectly good two argument candidates. Fine. Been there, seen that. I can use disable_if to make sure that the second range based version is only "active" when the arguments are different types. It's verbose, but it (usually) works template<class Range, class Compare> typename boost::disable_if_c<boost::is_same<Range, Compare>::value, std::pair<typename boost::range_iterator<const Range>::type, typename boost::range_iterator<const Range>::type> >::type foo ( const Range &r, Compare comp ); But this time it does not! I get a compile error telling me that the compiler can't deal with boost::range_iterator<XXX>::type, when XXX = some random iterator. It seems that the compiler wants to evaluate all the parameters of disable_if_c before deciding whether or not to SFINAE it (I guess that's not unreasonable, but it's not what I want) Apparently, all the other times that I did this, the return type of the function was not a dependent type of the template arguments. Any suggestions for a workaround here? -- Marshall -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

4 9

[enable_if] compile failure in trunk
by Tim Blechmann 05 Dec '11

05 Dec '11

trying to merge boost.heap into trunk, there is one issue, which seems to be triggered by the enable_if in the boost.heap testsuite. compiling with gcc (4.5 or 4.6), i get the following error: In file included from /home/tim/workspace/boost-trunk/boost/parameter.hpp:17:0, from /home/tim/workspace/boost-trunk/boost/heap/policies.hpp:12, from /home/tim/workspace/boost-trunk/boost/heap/detail/stable_heap.hpp:20, from /home/tim/workspace/boost_heap/libs/heap/test/../../../boost/heap/fibonacci_heap.hpp:20, from /home/tim/workspace/boost_heap/libs/heap/test/fibonacci_heap_test.cpp:8: /home/tim/workspace/boost-trunk/boost/parameter/name.hpp:52:1: error: template argument 2 is invalid In file included from /home/tim/workspace/boost-trunk/boost/fusion/support/detail/segmented_fold_until_impl.hpp:20:0, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin_impl.hpp:15, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector10.hpp:15, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector_fwd.hpp:14, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/tuple/tuple.hpp:11, from /home/tim/workspace/boost-trunk/boost/fusion/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/include/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/math/tools/tuple.hpp:89, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/igamma_inverse.hpp:13, from /home/tim/workspace/boost-trunk/boost/math/special_functions/gamma.hpp:1543, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/bessel_jy.hpp:14, from /home/tim/workspace/boost-trunk/boost/math/special_functions/bessel.hpp:17, from /home/tim/workspace/boost-trunk/boost/math/special_functions.hpp:18, from /home/tim/workspace/boost-trunk/boost/random/generate_canonical.hpp:22, from /home/tim/workspace/boost-trunk/boost/random.hpp:52, from /home/tim/workspace/boost_heap/libs/heap/test/mutable_heap_tests.hpp:1, from /home/tim/workspace/boost_heap/libs/heap/test/fibonacci_heap_test.cpp:12: /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:77:9: error: expected nested-name-specifier before ‘enable_if’ /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:77:18: error: expected initializer before ‘<’ token /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:88:9: error: expected nested-name-specifier before ‘enable_if’ /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:88:18: error: expected initializer before ‘<’ token /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:98:31: error: ‘boost::fusion::iterator_operators::operator==’ has not been declared /home/tim/workspace/boost-trunk/boost/fusion/iterator/equal_to.hpp:99:31: error: ‘boost::fusion::iterator_operators::operator!=’ has not been declared In file included from /home/tim/workspace/boost-trunk/boost/fusion/iterator/segmented_iterator.hpp:13:0, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:11, from /home/tim/workspace/boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector10.hpp:15, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector_fwd.hpp:14, from /home/tim/workspace/boost-trunk/boost/fusion/container/vector/vector.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/tuple/tuple.hpp:11, from /home/tim/workspace/boost-trunk/boost/fusion/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/fusion/include/tuple.hpp:10, from /home/tim/workspace/boost-trunk/boost/math/tools/tuple.hpp:89, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/igamma_inverse.hpp:13, from /home/tim/workspace/boost-trunk/boost/math/special_functions/gamma.hpp:1543, from /home/tim/workspace/boost-trunk/boost/math/special_functions/detail/bessel_jy.hpp:14, from /home/tim/workspace/boost-trunk/boost/math/special_functions/bessel.hpp:17, from /home/tim/workspace/boost-trunk/boost/math/special_functions.hpp:18, from /home/tim/workspace/boost-trunk/boost/random/generate_canonical.hpp:22, from /home/tim/workspace/boost-trunk/boost/random.hpp:52, from /home/tim/workspace/boost_heap/libs/heap/test/mutable_heap_tests.hpp:1, from /home/tim/workspace/boost_heap/libs/heap/test/fibonacci_heap_test.cpp:12: /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:91:22: error: expected nested-name-specifier before ‘disable_if’ /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:91:32: error: expected ‘,’ or ‘...’ before ‘<’ token /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:122:18: error: expected nested-name-specifier before ‘disable_if’ /home/tim/workspace/boost-trunk/boost/fusion/container/list/cons.hpp:122:28: error: expected initializer before ‘<’ token compiling with gcc against 1.48 works fine. clang++ correctly compiles this code against boost-trunk. any idea, what could go wrong there? thanks, tim

2 2

[units] - learning to use
by Janek Kozicki 05 Dec '11

05 Dec '11

Hi, I wrote a short function that integrates Huyghens spherical wave for diffraction. (This is a single slit experiment btw). I have some questions, marked with (*) double integral( const quantity<length> x // x - position where light intensity is calculated , const quantity<length> R // R - distance from slit to screen , const quantity<length> D // D - slit width , const quantity<length> lambda // lambda - wavelength , double steps // steps - number of integration steps // (*) ) { complex<double> i(0,1); complex<double> a(0); static const double pi = 3.14159265358979323846; // (**) quantity<wavenumber,complex<double> > k=2*pi/lambda; quantity<length> d=-0.5*D; // d - position on the slit quantity<length> dd=D/steps; // dd - width of integral step // integrate from -d to d: exp(i*k*r)/r for( ; d<= 0.5*D ; d+=dd ) { quantity<length> r=sqrt(pow<2>(R)+pow<2>(x-d)); a += (dd*exp(i*k*r)/r).value(); // (***) } return pow<2>(abs(a)); } (*) it should be `int steps` but if I write it this way I get a compilation error here: quantity<length> dd=D/steps; // dd - width of integral step That looks like a conversion problem. (**) why do I need to define pi ? I expected to find it somewhere, but I couldn't. (***) it seems strange that I need to take .value() here. The result is dimensionless, why can't it directly convert to complex<double> ? There is a risk that .value() would be expressed in millimeters or angstroms or whatever (maybe depending on dd), and then .value() would return a wrongly scaled number? Another question, why this works: quantity<length> wavelength ( 632.8 *nano*meters); and this does not? quantity<length> wavelength = 632.8 *nano*meters; Of course I know about extra copying, and waste of CPU resources on execution, when compiler isn't able to optimize this away (and usually it is able to do that). But why the heck this simple assignment can't work? PS: I am attaching a short test version of this program, it's in polish, but I hope you don't mind. best regards and thanks in advance for your help -- Janek Kozicki http://janek.kozicki.pl/ |

5 22

New Container: Hashed Vector
by Sam Hertz 05 Dec '11

05 Dec '11

Boost Developers, Let me start by saying that I love the Boost Libraries. I use them frequently. Most of the time, when I need some unique data structure in my code, Boost can solve my problems. I saw the recent release of the Container library and I love the idea of the flat_set/map structures. In my code, I require a data structure that has fast associative lookup (like an unordered_set). However, this data structure should preserve the order of element insertion. In other words, the data structure would be similar to the flat_set/map structures, but would preserve order of insertion instead of relying on the < operator or a Comparable function object. Right now, I am calling this structure a hashed_vector. I am aware of Boost.Multi-Index, but this library is very general purpose and cumbersome to use to implement a hashed_vector. Ideally the structure would have an identical interface to the std::vector class, but with a much speedier find member function. Right now I am creating a wrapper class for multi_index_container to implement the hashed_vector, but hopefully a more direct implementation could be added to the Boost Libraries. I am sharing this idea with all of you because I want to see if you think such a structure is worth including in the libraries and if anyone is interested in implementing it. I would love to implement it myself, but I am currently a full-time graduate student and my experience with template programming is laughable when considering the amount currently used in the Boost Libraries. Looking forward to your feedback! Sam

2 1

[smart-ptr][containers] type of the operator[] index
by Vicente J. Botet Escriba 05 Dec '11

05 Dec '11

Hi, which is the correct type used as index of operator[]. scoped_array uses std::ptrdiff_t. Others containers use std::size_t. The standard uses also std::size_t, but in 13.6 Built-in operators 13 For every cv-qualified or cv-unqualified object type T there exist candidate operator functions of the form T* operator+(T*, std::ptrdiff_t); T& operator[](T*, std::ptrdiff_t); T* operator-(T*, std::ptrdiff_t); T* operator+(std::ptrdiff_t, T*); T& operator[](std::ptrdiff_t, T*); we see again std::ptrdiff_t. When using an index to move from a scoped_array to another container which should be the type if the index? Best, Vicente

6 19

[thread][general] Using and building the library
by Vicente J. Botet Escriba 04 Dec '11

04 Dec '11

Hi, there is a ticket for the Boost.Thread #4921 BOOST_THREAD_USE_DLL and BOOST_THREAD_USE_LIB are crucial and need to be documented (https://svn.boost.org/trac/boost/ticket/4921) related to the documentation of how the library can be used and build. Boost.Config provides some tools that the library authors can adopt, but is there a documented way to do it? If yet could you point it Here it is what could be added to for Boost.Thread Using and building the library Boost.Thread is configured following the conventions used to build libraries with separate source code (http://www.boost.org/doc/libs/1_48_0/libs/config/doc/html/boost_config/boos…) Boost.Thread will import/export the code only if the user has specifically asked for it, by defining either BOOST_ALL_DYN_LINK if they want all boost libraries to be dynamically linked, or BOOST_THREAD_DYN_LINK if they want just this one to be dynamically liked. The source code compiled when building the library defines a macros BOOST_THREAD_SOURCE that is used to import or export it. The user must not define this macro in any case. Best, Vicente

1 0

[parameter] Boost.Graph program not responding at run-time
by Lorenzo Caminiti 03 Dec '11

03 Dec '11

Hello all, If I move the call to boost::depth_first_search into a template depth_first_search_impl and out of the Boost.Parameter function body, the code compiles (both MSVC and GCC with latest Boost from trunk) but the executable runs forever and prints nothing to cout... What am I doing wrong? #include <boost/parameter.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/depth_first_search.hpp> #include <boost/graph/graph_traits.hpp> #include <boost/range/irange.hpp> #include <boost/pending/indirect_cmp.hpp> #include <boost/type_traits/is_convertible.hpp> #include <boost/type_traits/is_integral.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/mpl/and.hpp> #include <boost/mpl/placeholders.hpp> #include <iostream> namespace graphs { template< typename G > struct vertex_descriptor { typedef typename boost::graph_traits<G>::vertex_descriptor type; }; template< typename T > struct is_incidence_and_vertex_list_graph : boost::mpl::and_< boost::is_convertible< typename boost::graph_traits<T>::traversal_category , boost::incidence_graph_tag > , boost::is_convertible< typename boost::graph_traits<T>::traversal_category , boost::vertex_list_graph_tag > > {}; template< typename T, typename Key > struct is_property_map_of_key : boost::is_same<Key, typename boost::property_traits<T>::key_type> {}; template< typename T, typename Key > struct is_integral_property_map_of_key { typedef typename boost::mpl::and_< boost::is_integral<typename boost::property_traits<T>::value_type> , is_property_map_of_key<T, typename Key::type> >::type type; static const bool value = type::value; }; template< typename Size, typename IndexMap > boost::iterator_property_map<boost::default_color_type*, IndexMap, boost::default_color_type, boost::default_color_type&> default_color_map ( Size const& num_vertices, IndexMap const& index_map ) { std::vector<boost::default_color_type> colors(num_vertices); return &colors[0]; } template< typename graph_type, typename visitor_type, typename root_vertex_type, typename index_map_type, typename color_map_type > void depth_first_search_impl ( graph_type graph, visitor_type visitor, root_vertex_type root_vertex, index_map_type index_map, color_map_type color_map ) { boost::depth_first_search(graph, boost::visitor(visitor). color_map(color_map).root_vertex(root_vertex). vertex_index_map(index_map)); } BOOST_PARAMETER_NAME(graph) BOOST_PARAMETER_NAME(visitor) BOOST_PARAMETER_NAME(root_vertex) BOOST_PARAMETER_NAME(index_map) BOOST_PARAMETER_NAME(color_map) BOOST_PARAMETER_FUNCTION( (void), depth_first_search, tag, (required (graph, *(is_incidence_and_vertex_list_graph<boost::mpl::_>)) ) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, (vertex_descriptor<tag::graph::_>), *boost::vertices(graph).first) (index_map, *(is_integral_property_map_of_key< boost::mpl::_, vertex_descriptor<tag::graph::_> >), boost::get(boost::vertex_index, graph)) (in_out(color_map), *(is_property_map_of_key< boost::mpl::_, vertex_descriptor<tag::graph::_> >), default_color_map(boost::num_vertices(graph), index_map)) ) ) { return depth_first_search_impl<graph_type, visitor_type, root_vertex_type, index_map_type, color_map_type>(graph, visitor, root_vertex, index_map, color_map); } } // namespace graphs template< typename TimeMap > struct dfs_time_visitor : public boost::default_dfs_visitor { typedef typename boost::property_traits<TimeMap>::value_type T; dfs_time_visitor ( TimeMap dmap, TimeMap fmap, T& t ) : dmap_(dmap), fmap_(fmap), time_(t) {} template< typename V, typename G > void discover_vertex ( V u, G const& g ) const { put(dmap_, u, time_++); } template< typename V, typename G > void finish_vertex ( V u, G const& g ) const { put(fmap_, u, time_++); } private: TimeMap dmap_; TimeMap fmap_; T& time_; }; int main ( void ) { typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS> G; typedef boost::graph_traits<G>::vertices_size_type size_type; enum {u, v, w, x, y, z, N}; char names[] = {'u', 'v', 'w', 'x', 'y', 'z'}; typedef std::pair<int, int> E; E edges[] = {E(u, v), E(u, x), E(x, v), E(y, x), E(v, y), E(w, y), E(w, z), E(z, z)}; G g(edges, edges + sizeof(edges) / sizeof(E), N); std::vector<size_type> dtime(boost::num_vertices(g)); std::vector<size_type> ftime(boost::num_vertices(g)); size_type t = 0; dfs_time_visitor<size_type*> vis(&dtime[0], &ftime[0], t); graphs::depth_first_search(g, vis); std::vector<size_type> dorder(N); boost::integer_range<size_type> r(0, N); std::copy(r.begin(), r.end(), dorder.begin()); std::sort(dorder.begin(), dorder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&dtime[0])); std::cout << "order of discovery: "; for(int i = 0; i < N; ++i) std::cout << names[dorder[i]] << " "; std::cout << std::endl; std::vector<size_type> forder(N); std::copy(r.begin(), r.end(), forder.begin()); std::sort(forder.begin(), forder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&ftime[0])); std::cout << "order of finish: "; for(int i = 0; i < N; ++i) std::cout << names[forder[i]] << " "; std::cout << std::endl; return 0; } Thanks. --Lorenzo

2 6

Phoenix documentation problems
by Dave Abrahams 03 Dec '11

03 Dec '11

A few things I just noticed: 1. http://www.boost.org/doc/libs/release/libs/phoenix/doc/html/phoenix/what_s_… says: "Bind is no completely compatible with Boost.Bind" There's a letter missing after "no," the choice of which ("w" or "t") can invert the meaning of the sentence! It wasn't until I got to http://www.boost.org/doc/libs/release/libs/phoenix/doc/html/phoenix/modules… that I realized it was "w"! 2. On the same page I think there's a messed up cross-reference, because "phoenix.modules.function phoenix::function" Doesn't make a whole lot of sense. 3. On libs/phoenix/doc/html/phoenix/starter_kit/values.html I see: Confused? val(3) is a unary function, you say? Yes it is. No, it isn't. val is a unary function. val(3) *invokes* a unary function. 4. libs/phoenix/doc/html/phoenix/starter_kit/lazy_operators.html says that x[ref(i)] is an error but it gives only a confusing partial explanation that doesn't seem to follow the rules above it. operator[] looks as much like a binary operation as operator*; the difference is that the former must be a member. 5. Can we please, finally, *deprecate* Boost.Lambda and put a sign on its docs directing people to look at Phoenix? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 3

[1.49.0] New libraries?
by Beman Dawes 03 Dec '11

03 Dec '11

What new libraries are ready for 1.49.0? What is that state of any new libraries that want to go in 1.49.0? Are they in trunk and do the developers think they are ready to be merged into release? The release managers would like to have a four week beta period of 1.49.0. That means we have to get going on new libraries right way if we are going meet our early February release schedule. --The release team

6 12

[thread] patch to allow custom stack size.
by Brett Lentz 03 Dec '11

03 Dec '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patch and (very) rudimentary usage example is attached. A couple months ago, I sent mail to the list looking to see if there's interest in getting some patches merged from Phusion Passenger. (See: http://marc.info/?t=131722868200003&r=1&w=2 ) So, here's the first patch I'd like to try to get committed. On pthread-based systems, it allows for the user to request a custom stack size. This is useful in Passenger's case where they want to reduce the VM size without requiring the user to hassle with ulimit settings. Passenger spawns many threads rather than using a thread pool for performance reasons. As a result of this design decision, they also need the ability to tune the stack size. Ticket #5956 already exists for this patch. I've verified that the patch works against the current (1.49) codebase out of SVN. What next steps need to be taken before this is committed? - -- - ---Brett. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1lZEAAoJEEAzW/nB31+3fx4H/iulwAM7vGlZW56xsuezTXPC 6SSuYzUlkyVeCngpireVyD0+Um/ACFBM8FSf76cRnewX5449T01IycmX3fUe+z7g DjjUCQAHJ/9pdfrqEHz0d7wZcZbeBHUm2zggdDGcn703JQSagg2Q5d5mz48RU8/J ixTe/oAOAaXk5TQo/92fHrAmtpwfQON4tPsS7Om0kJ5vcv3PbIqQ0Q4eBKRJCVHI /CFfc3xXwSaR1xUkwhPHtjydlIWAMo0+bdKgJE5HGnn6fQSU5jlZ+ihDyajOmM88 ueaIcWi7pa3OZwLzrUNG0xIH4m7wtk0ga8edym4+ZvuovUi4vYRA1k4dIzBOtvg= =0dQJ -----END PGP SIGNATURE-----

6 14