February 2014 - Boost-users - lists.preview.boost.org

Question on writing HTTP parser
by gomti 25 Feb '14

25 Feb '14

Hello. I'm newbie for boost library. I'm trying to write a HTTP Parser, which handles the HTTP message coming from the proxy server. I don't know much about the boost, so I'm really confused on what to use to write my functionality. When I search on the internet, some say that I need to used Boost.Asio and Some say Boost.Spirit. When I looked over the document for each, I found that Boost.Asio is like network library for C++ and Boost.Spirit is for writing compilers. As I mention above, I want to write a http parser. I think the relevant one is the following: https://github.com/joyent/http-parser Please give me some advice. Since this is my first posting, I don't know the culture in this mailing list so if I'm doing some mistake in here, please let me know. Thanks.

3 3

Parallel Dijkstra with Predecessors
by Florian Meier 25 Feb '14

25 Feb '14

Hi, I am trying to use the parallel Dijkstra implementation with predecessors, but I am not able to compile it. Please have a look at the following diff against boost_1_53_0/libs/graph_parallel/example/dijkstra_shortest_paths.cpp (You can find the modified version attached.) ------------------------------------------- @@ -45,8 +45,10 @@ /* An undirected, weighted graph with distance values stored on the vertices. */ +typedef adjacency_list_traits<vecS, distributedS<mpi_process_group, vecS>, undirectedS>::vertex_descriptor vertex_descriptor; + typedef adjacency_list<vecS, distributedS<mpi_process_group, vecS>, undirectedS, - /*Vertex properties=*/property<vertex_distance_t, float>, + /*Vertex properties=*/property<vertex_distance_t, float, property<vertex_predecessor_t, vertex_descriptor> >, /*Edge properties=*/property<edge_weight_t, float> > Graph; @@ -71,7 +73,7 @@ // Compute shortest paths from vertex 0 dijkstra_shortest_paths(g, start, - distance_map(get(vertex_distance, g))); + distance_map(get(vertex_distance, g)).predecessor_map(get(vertex_predecessor, g))); // Output a Graphviz DOT file std::string outfile = filename; ------------------------------------------- This (actually get(vertex_predecessor, g)) gives me ------------------------------------------- In file included from /usr/include/boost/property_map/parallel/distributed_property_map.hpp:706:0, from /usr/include/boost/property_map/property_map.hpp:645, from /usr/include/boost/graph/properties.hpp:19, from /usr/include/boost/mpi/graph_communicator.hpp:30, from /usr/include/boost/mpi.hpp:27, from /usr/include/boost/graph/distributed/mpi_process_group.hpp:30, from dijkstra_shortest_paths.cpp:16: /usr/include/boost/property_map/parallel/impl/distributed_property_map.ipp: In instantiation of ‘void boost::parallel::distributed_property_map<ProcessGroup, GlobalMap, StorageMap>::handle_message<Reduce>::handle_multiput(int, int, const std::vector<boost::unsafe_pair<typename boost::property_traits<StorageMap>::key_type, typename boost::property_traits<StorageMap>::value_type> >&, boost::graph::parallel::trigger_receive_context) [with Reduce = boost::property_reduce<boost::vertex_predecessor_t>::apply<boost::detail::parallel::global_descriptor<long unsigned int> >; ProcessGroup = boost::graph::distributed::mpi_process_group; GlobalMap = boost::detail::parallel::global_descriptor_property_map<long unsigned int>; StorageMap = boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>*, boost::detail::parallel::global_descriptor<long unsigned int>, boost::detail::parallel::global_descriptor<long unsigned int>&, boost::vertex_predecessor_t>; typename boost::property_traits<StorageMap>::value_type = boost::detail::parallel::global_descriptor<long unsigned int>; typename boost::property_traits<StorageMap>::key_type = long unsigned int]’: /usr/include/boost/property_map/parallel/impl/distributed_property_map.ipp:255:18: required from ‘void boost::parallel::distributed_property_map<ProcessGroup, GlobalMap, StorageMap>::handle_message<Reduce>::setup_triggers(boost::parallel::distributed_property_map<ProcessGroup, GlobalMap, StorageMap>::process_group_type&) [with Reduce = boost::property_reduce<boost::vertex_predecessor_t>::apply<boost::detail::parallel::global_descriptor<long unsigned int> >; ProcessGroup = boost::graph::distributed::mpi_process_group; GlobalMap = boost::detail::parallel::global_descriptor_property_map<long unsigned int>; StorageMap = boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, shor t int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>*, boost::detail::parallel::global_descriptor<long unsigned int>, boost::detail::parallel::global_descriptor<long unsigned int>&, boost::vertex_predecessor_t>; boost::parallel::distributed_property_map<ProcessGroup, GlobalMap, StorageMap>::process_group_type = boost::graph::distributed::mpi_process_group]’ /usr/include/boost/property_map/parallel/impl/distributed_property_map.ipp:35:3: required from ‘boost::parallel::distributed_property_map<ProcessGroup, GlobalMap, StorageMap>::distributed_property_map(const ProcessGroup&, const GlobalMap&, const StorageMap&, const Reduce&) [with Reduce = boost::property_reduce<boost::vertex_predecessor_t>::apply<boost::detail::parallel::global_descriptor<long unsigned int> >; ProcessGroup = boost::graph::distributed::mpi_process_group; GlobalMap = boost::detail::parallel::global_descriptor_property_map<long unsigned int>; StorageMap = boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, floa t> > >, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>*, boost::detail::parallel::global_descriptor<long unsigned int>, boost::detail::parallel::global_descriptor<long unsigned int>&, boost::vertex_predecessor_t>]’ /usr/include/boost/graph/distributed/adjacency_list.hpp:3468:50: required from ‘typename boost::property_map<boost::adjacency_list<OutEdgeListS, boost::distributedS<ProcessGroup, InVertexListS, InDistribution>, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, Property>::type boost::get(Property, boost::adjacency_list<OutEdgeListS, boost::distributedS<ProcessGroup, InVertexListS, InDistribution>, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>&) [with Property = boost::vertex_predecessor_t; OutEdgeListS = boost::vecS; ProcessGroup = boost::graph::distributed::mpi_process_group; InVertexListS = boost::vecS; InDistribution = boost::defaultS; DirectedS = boost::undirectedS; VertexProperty = boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >; EdgeProperty = boost::property<boost::edge_weight_t, float>; GraphProperty = boost::no_property; EdgeL istS = boost::listS; typename boost::property_map<boost::adjacency_list<OutEdgeListS, boost::distributedS<ProcessGroup, InVertexListS, InDistribution>, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, Property>::type = boost::parallel::distributed_property_map<boost::graph::distributed::mpi_process_group, boost::detail::parallel::global_descriptor_property_map<long unsigned int>, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<b oost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>*, boost::detail::parallel::global_descriptor<long unsigned int>, boost::detail::parallel::global_descriptor<long unsigned int>&, boost::vertex_predecessor_t> >]’ dijkstra_shortest_paths.cpp:77:106: required from here /usr/include/boost/property_map/parallel/impl/distributed_property_map.ipp:236:47: error: no match for call to ‘(boost::property_reduce<boost::vertex_predecessor_t>::apply<boost::detail::parallel::global_descriptor<long unsigned int> >) (const long unsigned int&, boost::parallel::distributed_property_map<boost::graph::distributed::mpi_process_group, boost::detail::parallel::global_descriptor_property_map<long unsigned int>, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t, float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_distance_t , float, boost::property<boost::vertex_predecessor_t, boost::detail::parallel::global_descriptor<long unsigned int> > >, boost::property<boost::edge_locally_owned_t, bool, boost::property<boost::edge_target_processor_id_t, short int, boost::property<boost::edge_weight_t, float> > >, boost::no_property, boost::listS>*, boost::detail::parallel::global_descriptor<long unsigned int>, boost::detail::parallel::global_descriptor<long unsigned int>&, boost::vertex_predecessor_t> >::value_type&, const boost::detail::parallel::global_descriptor<long unsigned int>&)’ values[i].second)); ^ In file included from /usr/include/boost/graph/distributed/breadth_first_search.hpp:23:0, from /usr/include/boost/graph/breadth_first_search.hpp:404, from /usr/include/boost/graph/dijkstra_shortest_paths.hpp:21, from dijkstra_shortest_paths.cpp:19: /usr/include/boost/graph/parallel/properties.hpp:90:11: note: candidates are: class apply ^ /usr/include/boost/graph/parallel/properties.hpp:95:9: note: T boost::property_reduce<boost::vertex_predecessor_t>::apply<T>::operator()(T) const [with T = boost::detail::parallel::global_descriptor<long unsigned int>] T operator()(T key) const { return key; } ^ /usr/include/boost/graph/parallel/properties.hpp:95:9: note: candidate expects 1 argument, 3 provided /usr/include/boost/graph/parallel/properties.hpp:96:9: note: T boost::property_reduce<boost::vertex_predecessor_t>::apply<T>::operator()(T, T, T) const [with T = boost::detail::parallel::global_descriptor<long unsigned int>] T operator()(T key, T, T y) const { return y; } ^ /usr/include/boost/graph/parallel/properties.hpp:96:9: note: no known conversion for argument 1 from ‘const long unsigned int’ to ‘boost::detail::parallel::global_descriptor<long unsigned int>’ ------------------------------------------- What is wrong here? Greetings, Florian

2 1

boost/graph/metric_tsp_approx.hpp patch, is there interest?
by Paolo Bolzoni 25 Feb '14

25 Feb '14

Dear list, In the boost/graph/metric_tsp_approx.hpp:224 is a note // TODO: This is will be O(n^2) if vertex storage of g != vecS. Since I am exactly in this situation I made a patch for my use, I added a bundled property to MSTImpl's vertices to contain a descriptor to keep track of the original graph vertices. It is a small modification, but since there is a TODO perhaps there is interest? If so how should I share it? Of course any comment is welcome. Your sincerely, Paolo

1 0

[icl] Icl broken for c++11's hint semantics. Fix provided.
by Joachim Faulhaber 25 Feb '14

25 Feb '14

Dear Icl users, due to a subtle effect of the changed hint semantics for associative containers, the icl library is broken in versions <= 1.55.0 when used with new STL-libraries that implement the new c++11 standard. This bug is fixed in the upcoming Boost 1.56.0. (see regression tests at http://www.boost.org/development/tests/master/developer/icl.html) Since the release of boost 1.56.0 seems to take longer than planned due to restructuring efforts for modular-boost, users of Boost.Icl affected by the problem may choose to pull the fixed Boost.Icl directly from the git repository and replace your_boost_1_55_0/boost/icl with the new code. The libs/icl part does not need an update. Another possibility is to apply the patch-file diff_icl_1_55_0_and_master.patch that is attached to this post to your local boost library 1.55.0: 1. cd to your_boost_1_55_0 root directory. your_boost_1_55_0> 2. From the command line type your_boost_1_55_0> patch -p2 < diff_icl_1_55_0_and_master.patch You may check the patched library by moving to your_boost_1_55_0/libs/icl/test and run your_boost_1_55_0/libs/icl/test> bjam Sorry for the inconvenience. Best regards, Joachim P.S.: For those interested in details of the issue here is a report: The semantics of insertion with hint in associative containers changed in c++11 form insert-after-hint (c++98/03) to insert-before-hint (c++11) see e.g. proposal N1780: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html so for an associative container c of type C, a value x and an iterator hint c.insert(hint, x); //tries to insert x right after hint in c++98 c.insert(hint, x); //tries to insert x before hint in c++11 In accordance with this behavior, if using the insert function std::pair<bool, iterator> C::insert(value_type const& x); (success, hint) = c.insert(x); the iterator hint of unsuccessful insertion is the matching hint, pointing to [c++98] the last element y in c that is not greater x, so x can be inserted *after* that hint. [c++11] the first element z in c that is greater than x, so x can be inserted *before* that hint. In Boost.Icl I used the returned hint-iterator of the insert function, that always returned the last overlapping interval y for an inserted interval x given the interval's exclusive-less ordering under c++98. With the changed hint semantics, this returned hint-iterator did not point to the last interval y overlapping x anymore but to the first interval z not overlapping x. Therefore the code was broken and returned false results. -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

Intrusive unordered set and thread safety
by Dave Davoren 25 Feb '14

25 Feb '14

Hi, I have been playing around with the boost intrusive unordered set. If my application is multi-threaded I do not see any way to make the set thread safe at a bucket level. I have seen a previous post from November 2012 "[Intrusive] unordered_set and thread safety" which asked the same question. At that point it was not implemented but I have not seen any updates in that area since. My question is, has it been implemented or is there a plan to implement such a feature in the near future? Thank you, Dave.

2 2

Re: [Boost-users] [interprocess] Shared memory object
by Ahmed Charles 24 Feb '14

24 Feb '14

Windows doesn't have to write to disk if there is no memory pressure in the case of a page file but if you have an explicit file being mapped, then you'll get writes to disk. This hypothesis should be easy to observe by monitoring the disk activity during your perf tests. ________________________________ From: Davies, John Sent: 2/21/2014 1:28 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [interprocess] Shared memory object >From my reading, the Windows version is faster but it doesn't have the persistence as the Linux version. The description mentions this: A class that wraps the native Windows shared memory that is implemented as a file mapping of the paging file. Unlike shared_memory_object<http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/shared_mem…>, windows_shared_memory<http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/windows_sh…> has no kernel persistence and the shared memory is destroyed when all processes destroy all their windows_shared_memory<http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/windows_sh…> objects and mapped regions for the same shared memory or the processes end/crash. Boost lets you choose what means more to you. ___________________________________ John Davies Contractor Home Respiratory Care Philips Home Healthcare Solutions 1740 Golden Mile Highway Monroeville, PA 15146 Email: john.davies(a)philips.com Fax: 724-387-4109 From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Patrick Steele Sent: Thursday, February 20, 2014 11:40 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [interprocess] Shared memory object Tests at the time were showing the Windows version to operate about twice as fast. If nothing has changed I guess I will remain with it then. I had just been hoping for the code to be more platform dependent. On 20 February 2014 14:44, Ion Gaztañaga <igaztanaga(a)gmail.com<mailto:igaztanaga@gmail.com>> wrote: El 20/02/2014 11:42, Patrick Steele escribió: Hi, can anyone tell me if there is a performance or other difference between boost::interprocess::shared_memory_object and boost::interprocess::windows_shared_memory? With the version of boost we were using back in 2011 ( boost 1.48 ), we found that windows_shared_memory operated faster than shared_memory_object when transporting around 10MB of data. Is this still the case? Thanks, Nothing has changed AFAIK. shared_memory_object is a memory mapped file whereas windows_shared_memory is backed by the pagefile. I don't know why Windows should make one faster than the other, though. Best, Ion _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org<mailto:Boost-users@lists.boost.org> http://lists.boost.org/mailman/listinfo.cgi/boost-users ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[iostreams] gzip problem
by Olaf Krzikalla 24 Feb '14

24 Feb '14

Hi @boost, I have a file format containing chunks of gzipped data (using gzip_decompressor/gzip_compressor). Inbetween these chunks there is other (plain) data. So can keep the archive seekable. However apparently this doesn't work out as it should. Whenever gzip_decompressor reaches the end of a chunk it throws an exception. The trouble-making line is in basic_gzip_decompressor::read: if (footer_.done()) { if (footer_.crc() != this->crc()) boost::throw_exception(gzip_error(gzip::bad_crc)); int c = boost::iostreams::get(peek); if (traits_type::is_eof(c)) { ----------------------------- state_ = s_done; } else { peek.putback(c); base_type::close(peek, BOOST_IOS::in); state_ = s_start; header_.reset(); footer_.reset(); } } Thus after the footer is read and checked, the decompressor checks whether or not eof is reached. Obvisiously this isn't the case here - the decompressed chunk is just embedded in the file. Thus the decompressor restarts, but cannot find another header thus throwing an exception. Would it be reasonable to just insert a break? header_.reset(); footer_.reset(); + break; } } This would solve _my_ problem. Or is there another way to work around this issue? Best Olaf

2 2

boost serialize, exception "eaten" up...
by Robert Bielik 23 Feb '14

23 Feb '14

Hi all, I'm trying to make a deserialization user cancellable, and I thought, hey, if I throw an exception in a progress handler (used when reading chars from input stream), that would propagate through the load hieararchy and I can catch it at top level... Nope... it gets caught in iostream (VS2012, row 776) :( , so the _CATCH_IO_END is probably a catch(...). Not very nice, and quite counter-productive if you ask me. Any ideas how to get that exception out ? Regards /Robert

1 0

Build errors trying to build Boost with mingw-w64
by Da-Huntha 22 Feb '14

22 Feb '14

Hey all, I've been trying to build all Boost libraries with mingw-w64 on Windows 8 but some fail. I'm trying to build a 32bit windows release build. The following errors are an excerpt of all the build errors: >d:\win-builds-32\i686-w64-mingw32\include\dvec.h: In function 'F64vec2 IntToF64vec2(const >F64vec2&, int)': >d:\win-builds-32\i686-w64-mingw32\include\dvec.h:840:80: error: '_mm_cvtsi32_sd' was not declared in this scope > inline F64vec2 IntToF64vec2(const F64vec2 &a,int b) { return _mm_cvtsi32_sd(a,b >); } > >^ >In file included from ./boost/system/system_error.hpp:14:0, > from ./boost/thread/exceptions.hpp:22, The build is invoked with: >set PATH=%MINGW_HOME%\bin;%WINDDK_HOME%\7600.16385.1\bin\x86 >bjam toolset=gcc variant=release threading=multi link=static address-model=32 Does anyone understand why these errors are given? Am I missing some configuration?

1 0

[mpl][type_traits] Transforming to common type
by Bjorn Reese 22 Feb '14

22 Feb '14

Given a type T, I am trying to transform a type list into another containing the common type between T and the individual types in the type list. When I compile the example below, I get the following error: /usr/local/include/boost/type_traits/common_type.hpp:111:42: error: incompatible operand types ('mpl_::arg<1>' and 'int') typedef decltype(declval<bool>() ? declval<T>() : declval<U>()) type; ^ ~~~~~~~~~~~~ ~~~~~~~~~~~~ It appears that the placeholder is not expanded to its actual type. If I use, say, decay<> instead of common_type<>, the example works just fine. Does anybody know how I can make it work? Example code: #include <boost/mpl/vector.hpp> #include <boost/mpl/transform.hpp> #include <boost/type_traits/common_type.hpp> int main() { typedef boost::mpl::vector<int, double> sequence_types; typedef boost::mpl::transform< sequence_types, // This is causing the problem boost::common_type<boost::mpl::_1, int>::type >::type transformed_types; return 0; }

2 2