- Boost - lists.boost.org

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

[thread] [rfc] patch to change condition_variable and mutex error checks
by Brett Lentz 02 Dec '11

02 Dec '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patch is attached. I'd like to get some comments about this patch. Does it seem reasonable enough to accept? Is there a better way to handle it? BOOST_VERIFY aborts on EINTR, but EINTR is usually not fatal, it just means you need to try later. So, the attached patch makes it so that the condition_variable and mutex error checks retry on EINTR, but will still fail on any other error. This issue was uncovered on one of Phusion Passenger's customers' production systems. - -- - ---Brett. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1pVQAAoJEEAzW/nB31+3CgMIAMPYRMvuuYWdHbmWF7qWt13i pKRLGDjT5fT75SzVdcmwFNJLlboaP5tNi8g89Kw+iS+jjghEbyZr2Zx6BdCL67ne +XtA1DqlmNHD3GZiLMlQDdPqbV7qliqj4d7+8xXqXnivxULYPwQMzW1XXY8Cs4Ys uHBK/NrvZM+/LL2umHSCOLbKz7AEli6tSzuUyw557ubp42UPnE+gc+mUb7QYmcgW BKzizZ03s+V4qJA/B+N4Ux8RvvhWgNLXnYoC958mzvnTwaTbdGfEmzVkKaWucI50 jsEzfejn/Gru2BNeC2MwVmecxmkHugoXxvVUYIH4PaDET96BM3ihHWV+4SLg7ik= =xkyz -----END PGP SIGNATURE-----

3 6

[serialization] duplicate symbols when trying to BOOST_CLASS_EXPORT
by V D 02 Dec '11

02 Dec '11

Hi, I'm using boost serialization to serialize a bunch of classes, sometimes I need to serialize via a base pointer to a derived class. Let's consider the very simple case where we have a class B deriving from class A. /*** a.h ***/ #ifndef __A__H #define __A__H #include <iostream> class A { private: virtual void make_polymorphic() = 0; friend class boost::serialization::access; template <typename Archive> void serialize(Archive& ar, const unsigned int version) { std::cout << "A!\n"; } }; #endif /*** b.h ***/ #ifndef __B__H #define __B__H #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> #include "a.h" class B : public A { private: friend class boost::serialization::access; template <typename Archive> void serialize(Archive& ar, const unsigned int version) { ar & boost::serialization::base_object<A>(*this); std::cout << "B!\n"; } virtual void make_polymorphic() {} }; BOOST_CLASS_EXPORT(B); #endif I'm using the BOOST_CLASS_EXPORT so that it registers a GUID for class B, so that serialization of a base pointer to a derived class works. This works fine. My problem is that, if I have 2 files that include b.h, I will get duplicate symbols for B's guid. For example, suppose we add b.cpp with an empty default constructor, just so that we compile another file. #include "b.h" B::B() { } Let's use the following main: // main.cpp #include <iostream> #include <fstream> #include <boost/archive/binary_oarchive.hpp> #include "b.h" int main() { std::ofstream of("mybin.bin"); boost::archive::binary_oarchive oa(of); A* b = new B(); oa << b; return 0; } Which I compile with g++ main.cpp b.cpp -lboost_system -lboost_serialization -o main I get, ld: duplicate symbol boost::archive::detail::extra_detail::init_guid<B>::g If I don't have 2 files, then of course I don't have duplicate symbols and the serialization of the polymorphic object works fine. Any idea how to resolve this issue? Thank you -V

2 2

Boost.Log plan
by Leon 02 Dec '11

02 Dec '11

Hi, What's the current plan for Boost.Log? Will it be part of 1.49.0? Bests, Leon

2 1