- Boost-users - lists.boost.org

the asio example which implement the tcp long connection
by lx 10 Apr '14

10 Apr '14

hi : I want to learn how to implement long connection by asio.But I can't find example. So, where I can find ? Thank you.

1 0

conflicting intmax_t definitions - Boost 1.53 and gcc 4.8 incompatibility?
by Nate Finch 09 Apr '14

09 Apr '14

I recently upgraded to Ubuntu Trusty Tehr, and now the C++ project I'm working on won't build. It looks like the stdlib and Boost aren't working nicely together for some reason. A bunch of typedefs are conflicting between the two, below is one of the errors, where intmax_t is getting defined in two places. I'm not sure what changed, but I now have gcc (Ubuntu/Linaro 4.8.2-14ubuntu2) 4.8.2 and boost Version: 1.53.0.0ubuntu2 Here's an example error message: /usr/include/inttypes.h:290:8: error: reference to ‘intmax_t’ is ambiguous extern intmax_t imaxabs (intmax_t __n) __THROW __attribute__ ((__const__)); ^ In file included from /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stdint.h:9:0, from /usr/include/inttypes.h:27, from src/uint256.h:11, from src/key.h:12, from src/crypter.h:8, from src/keystore.h:8, from src/script.h:14, from src/script.cpp:11: /usr/include/stdint.h:134:19: note: candidates are: typedef long int intmax_t typedef long int intmax_t; ^ In file included from /usr/include/boost/math_fwd.hpp:12:0, from /usr/include/boost/math/common_factor_ct.hpp:13, from /usr/include/boost/variant/variant.hpp:44, from /usr/include/boost/variant.hpp:17, from src/script.h:12, from src/script.cpp:11: /usr/include/boost/cstdint.hpp:306:50: note: typedef boost::long_long_type boost::intmax_t typedef ::boost::long_long_type intmax_t; Any help would be much appreciated. I'm fine with downgrading something, I'm just not sure what to downgrade.... or if there's an actual fix, that's cool too. -- View this message in context: http://boost.2283326.n4.nabble.com/conflicting-intmax-t-definitions-Boost-1… Sent from the Boost - Users mailing list archive at Nabble.com.

8 20

Re: [Boost-users] [serialization] [multimap] change of element's order when deserialize
by Pablo Madoery 09 Apr '14

09 Apr '14

Thank you for your quick answer. I think I will use a map of vector instead of a multimap. On Wed, Apr 9, 2014 at 12:18 PM, Robert Ramey <robertmacleranramey(a)gmail.com > wrote: > > > On Wednesday, April 9, 2014 7:45:59 AM UTC-7, Pablo Madoery wrote: >> >> I have the following code: >> > > >> snip ... >> >> where you can see that the element's order is changed. >> >> When compiling it throw this warning: >> boost::mpl::print<boost::serialization::BOOST_ >> SERIALIZATION_STATIC_WARNING_LINE<98> > >> > > that I don't know what it means. > > You'll have to look into source code error stack to see the comment > associated with this warning. > > >> >> Is this a normal behavior of the serialization library? >> I am missing something ? >> > > This is a feature of the implementation of the serialization of multi map > as well as the implementation > of the std::multi map itself. The result is correct in that it's a valid > multimap but it is a different one that the original. > You could say it's an equivalent multimap. Should this have been done > differently? probably not. Trying > to guarantee this level of "equality" would couple the serialization > implementation to the > std::multimap implementation. This would add much work and never could be > entirely relied upon. > > If you want a specific order - don't use multi map. Expend your key size > and use map or set > > Robert Ramey > >

1 0

[serialization] [multimap] change of element's order when deserialize
by Pablo Madoery 09 Apr '14

09 Apr '14

I have the following code: #include <utility> #include <vector> #include <string> #include <fstream> #include <iostream> #include <map> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/string.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/utility.hpp> #include <boost/serialization/map.hpp> using namespace std; void print(multimap<pair<string, string>, int> &m) { multimap<pair<string, string>, int>::iterator it1 = m.begin(); multimap<pair<string, string>, int>::iterator it2 = m.end(); for(; it1!=it2; ++it1) { cout<<"key = "<<(it1->first).first<<(it1->first).second<<"\t\t"; cout<<"value = "<<(it1->second)<<endl; } cout<<endl; } int main() { multimap<pair<string, string>, int> m1; pair<string, string> par1("A", "B"); pair<string, string> par2("A", "B"); pair<string, string> par3("E", "F"); pair<string, string> par4("E", "F"); m1.insert(pair<pair<string, string>, int>(par1,10)); m1.insert(pair<pair<string, string>, int>(par2,20)); m1.insert(pair<pair<string, string>, int>(par3,30)); m1.insert(pair<pair<string, string>, int>(par4,40)); ofstream ofs("filename"); boost::archive::text_oarchive serial1(ofs); serial1 << m1; ofs.close(); ifstream ifs("filename"); boost::archive::text_iarchive serial2(ifs); multimap<pair<string, string>, int> m2; serial2 >> m2; cout<<"map1 = "<<endl; print(m1); cout<<endl; cout<<"map2 = "<<endl; print(m2); cout << "end" << endl; return 0; } What I am trying to do is serialize a multimap and then deserialize it. The problem i that the order of the elements is not conserved. This program gives as result the following: map1 = key = AB value = 10 key = AB value = 20 key = EF value = 30 key = EF value = 40 map2 = key = AB value = 20 key = AB value = 10 key = EF value = 40 key = EF value = 30 end where you can see that the element's order is changed. When compiling it throw this warning: boost::mpl::print<boost::serialization::BOOST_SERIALIZATION_STATIC_WARNING_LINE<98> > that I don't know what it means. Is this a normal behavior of the serialization library? I am missing something ?

1 0

shared_lock owner
by shada 09 Apr '14

09 Apr '14

did shared_lock has a member like visual c++ critical_section's owner? i use shared_lock in a game server, it has several hundred threads. if has owner, it more easy resolve deadlock.

2 2

After install, ld finds some boost libs, but not others. All are present.
by Devon Oslund 09 Apr '14

09 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can find boost_regex, can't find boost_system. Both right there. _________________________________________________________________________________________________________ ./bootstrap.sh --prefix=/usr ./b2 sudo ./b2 install /usr/lib$ ls -la /usr/lib/libboost_regex.* - -rw-r--r-- 1 root root 3022020 Apr 8 14:29 /usr/lib/libboost_regex.a lrwxrwxrwx 1 root root 24 Apr 8 14:29 /usr/lib/libboost_regex.so -> libboost_regex.so.1.55.0 - -rwxr-xr-x 1 root root 1453274 Apr 8 14:29 /usr/lib/libboost_regex.so.1.55.0 ls -la /usr/lib/libboost_system.* - -rw-r----- 1 root root 32482 Apr 8 14:29 /usr/lib/libboost_system.a lrwxrwxrwx 1 root root 25 Apr 8 14:29 /usr/lib/libboost_system.so -> libboost_system.so.1.55.0 - -rwxr-x--- 1 root root 20461 Apr 8 14:29 /usr/lib/libboost_system.so.1.55.0 **** Build of configuration Release for project TCCore_Batchd **** make all Building target: libTCCore_Batchd.so Invoking: GCC C++ Linker g++ -L/home/devonerik/workspace/tclink-4.0.1-C -L/home/devonerik/workspace/nacl-20110221/build/shalebridge/lib/amd64 - -L/home/devonerik/workspace/scrypt/Release -Xlinker -rpath . -shared -o "libTCCore_Batchd.so" {snip filenames} -lboost_system -lboost_regex -lscrypt -lpqxx /usr/bin/ld: cannot find -lboost_system collect2: error: ld returned 1 exit status make: *** [libTCCore_Batchd.so] Error 1 **** Build of configuration Release for project TCCore_Batchd **** make all Building target: libTCCore_Batchd.so Invoking: GCC C++ Linker g++ -L/home/devonerik/workspace/tclink-4.0.1-C -L/home/devonerik/workspace/nacl-20110221/build/shalebridge/lib/amd64 - -L/home/devonerik/workspace/scrypt/Release -Xlinker -rpath . -shared -o "libTCCore_Batchd.so" {snip filenames} -lboost_regex -lscrypt -lpqxx -lboost_system /usr/bin/ld: cannot find -lboost_system collect2: error: ld returned 1 exit status make: *** [libTCCore_Batchd.so] Error 1 **** Build Finished **** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRHG1AAoJEAy07rHw4yivheoH/jRaeucvmZhDAossFEAfiqkJ 8BPzoyGxzX+7aIZXFy9m8HlOo6CEWIAh20XB7iq31vYIq9NLaahcegZgzYX1SmGL T0y0LpmJgUlipcQHbLl0o0E3RWHk7olqCALNy2OBOHLgMYHxDF4tGRMQ6jnbo3xV JLMex5ai5TQwWNmciv7bLuHG/INnVEHVn/UVW2G/fgn7m9j8puhTcWmgbJIq6GAd Gusqqd8P4UZN5Umm1N4PmDtOoIuu2OLD6QvUoP3pM+QvJ5ZVY0nRPx/RDcrzdhoY 7WUDo2anrZiEaPFENUFnCJFBTf3pn7D+JJFeljoAhnqgNuShUjheuUMWsUV2/28= =hc+I -----END PGP SIGNATURE-----

3 3

BOOST_PP_REPEAT to repeat comma-containing text
by Igor R 08 Apr '14

08 Apr '14

Hello, I'm trying to repeat a group of actual parameters (passed to some 3d party plain-C "variadic" function). The function call looks like this: func(count, param1, param2, arr1[0], arr2[0], param1, param2, arr1[1], arr2[1], param1, param2, arr1[2], arr2[2] /* etc */); So essentially, I'd like to repeat (param1, param2, arr1[n], arr2[n]) group. What is the right way to invoke BOOST_PP_REPEAT in this case? Thanks.

2 3

[Graph] Run-time weight search
by Sensei 08 Apr '14

08 Apr '14

Dear all, after many speculations and your previous advice I've come to the conclusion that I still need your help :) The setting is simple: I have an oriented graph, and I have two nodes. I wish to find all paths from one node to the other. Some restrictions apply: - I *cannot* calculate weights except at run-time when needed, it's too costly; - I can, if you say it's needed, restrict the path length to a certain threshold. What can I relax? The "all paths". Since weights are costly, I could set for just the best path, i.e., the one with the lowest weight. I don't think it would be possible to find the optimum path, in case I cannot search for all possible paths, but I can be easily wrong. I'm not that skilled with BGL, so any help would be quite appreciated! I've read the Table of Contents, but at first I cannot see if this can be done. Thanks!

1 0

Problems calling make_reversed_graph in a call to dijkstra from version 1.48
by Berit Dangaard Brouer 08 Apr '14

08 Apr '14

Hi, First of all thank you for providign the boost BGL library. I use it extensively. I am having some problems with some code, that works just fine using boost version 1.46, but cannot compile using version 1.48 and higher. I have a Bidirectional Graph using bundled properties defined as: struct Port { Port(int index=-1, int type=-1, int port_code=0, string UN="NN", string name="NN", int service_id=-1 ): m_index(index), m_type(type), m_port_code( port_code), UNLOCODE(UN), m_name(name), m_service_id(service_id) {} int m_index; int m_type;//0 port, 1 port call int m_port_code; string UNLOCODE; string m_name; int m_service_id; }; struct Edge { Edge( int id=-1, int type=-1, double weight=0.0, double cost=0.0, double dual_cost=0.0, double util=0.0, double cap=0.0, double r_cap=0.0 ) : m_idx(id), m_type(type), m_weight(weight) , m_cost(cost), m_dual_cost(dual_cost), m_utilization(util), m_capacity(cap), m_res_cap(r_cap) {} unsigned int m_idx; int m_type;//0 is load edge, 1 is voyage edge, 2 forfeited edge (commodity link) double m_weight; //distance double m_cost; //cost - only on load/unload/transhipment edges double m_dual_cost; double m_utilization; double m_capacity; double m_res_cap; //residual capacity }; //Graph typedef adjacency_list< vecS , vecS , bidirectionalS, Port, Edge> mcf_graph; I am trying to make a call to dijkstra on a reversed graph as follows: (the reversed graph is also a filtered graph, but I do not think this is an issue: dijkstra_shortest_paths (make_reverse_graph(fg), before_p, predecessor_map ( &p[0] ).distance_map ( &d[0] ).weight_map ( get ( &Edge::m_weight, fg) ).vertex_index_map ( get ( vertex_index,fg ) ) ); which works fine in 1.46, but it seems in 1.48 I can no longer use make_reverse_graph(<mcf_graph&>) (returning a reverse graph) with the bundled properties from fg. and I get the error (compressed summary - full details attached) usr/include/boost/property_map/property_map.hpp:354:56: error: no match for 'operator[]' in '((const boost::bundle_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Port, Edge>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, Edge, double>&)pa)[k]' /usr/include/boost/property_map/property_map.hpp:354:56: note: candidate is: In file included from /usr/include/boost/graph/adjacency_list.hpp:44:0, from /home/chrkr/git/lsndp/include/ipheuristic.h:36, from /home/chrkr/git/lsndp/src/ipheuristic.cpp:29: /usr/include/boost/graph/properties.hpp:399:15: note: T& boost::bundle_property_map<Graph, Descriptor, Bundle, T>::operator[](boost::bundle_property_map<Graph, Descriptor, Bundle, T>::key_type) const [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Port, Edge>; Descriptor = boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>; Bundle = Edge; T = double; boost::bundle_property_map<Graph, Descriptor, Bundle, T>::reference = double&; boost::bundle_property_map<Graph, Descriptor, Bundle, T>::key_type = boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>] /usr/include/boost/graph/properties.hpp:399:15: note: no known conversion for argument 1 from 'const boost::detail::reverse_graph_edge_descriptor<boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int> >' to 'boost::bundle_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Port, Edge>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, Edge, double>::key_type {aka boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>}' From various sources I understand that as of 1.48 reverse graph is no longer an image of the graph, but another object, where I need the actual property maps and the property maps of the reversed graph, but I did not get much wiser on how to call dijkstra with the reversed graph given these new description. I tried defining the reverse graph as a separate object reverse_graph<mcf_graph> r_fg=reverse_graph(fg); dijkstra_shortest_paths (r_fg), before_p, predecessor_map ( &p[0] ).distance_map ( &d[0] ).weight_map ( get ( &Edge::m_weight, r_fg) ).vertex_index_map ( get ( vertex_index, r_fg ) ) ); indicating that I am not getting the right properties for the reverse graph: equired from here /usr/include/boost/graph/properties.hpp:420:44: error: no type named 'vertex_bundled' in 'class boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Port, Edge> >' /usr/include/boost/graph/properties.hpp:421:42: error: no type named 'edge_bundled' in 'class boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Port, Edge> >' /usr/include/boost/graph/properties.hpp:425:7: error: no type named 'vertex_bundled' in 'class boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Port, Edge> >' /usr/include/boost/graph/properties.hpp:429:7: error: no type named 'vertex_bundled' in 'class boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Port, Edge> >' /usr/include/boost/graph/properties.hpp:432:70: error: no type named 'vertex_bundled' in 'class boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Port, Edge> >' /usr/include/boost/graph/properties.hpp:434:7: error: no type named 'vertex_bundled' in 'class boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Port, Edge> >' /home/chrkr/git/lsndp/src/ipheuristic.cpp:939:132: error: no matching function for call to 'get(double Edge::*, boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Port, Edge> >&)' /home/chrkr/git/lsndp/src/ipheuristic.cpp:939:132: note: candidates are: In file included from /usr/include/boost/graph/adjacency_list.hpp:36:0, from /home/chrkr/git/lsndp/include/ipheuristic.h:36, from /home/chrkr/git/lsndp/src/ipheuristic.cpp:29: /usr/include/boost/property_map/property_map.hpp:179:19: note: template<class T> const T& get(const T*, std::ptrdiff_t) /usr/include/boost/property_map/property_map.hpp:179:19: note: template argument deduction/substitution failed: /home/chrkr/git/lsndp/src/ipheuristic.cpp:939:132: note: mismatched types 'const T*' and 'double Edge::*' In file included from /usr/include/boost/graph/graphviz.hpp:25:0, from /home/chrkr/git/lsndp/include/data.h:19, from /home/chrkr/git/lsndp/include/ipheuristic.h:46, from /home/chrkr/git/lsndp/src/ipheuristic.cpp:29: /usr/include/boost/property_map/dynamic_property_map.hpp:322:1: note: template<class Key> std::string boost::get(const string&, const boost::dynamic_properties&, const Key&) /usr/include/boost/property_map/dynamic_property_map.hpp:322:1: note: template argument deduction/substitution failed: Is the problem the bundled properties from the original graph or ? -- Best Regards, Ph.D. Berit Dangaard Brouer Post Doc. DTU Management Engineering, Management Science Technical University of Denmark Department of Management Engineering Produktionstorvet, Bygning 426 2800 Kgs. Lyngby blof(a)dtu.dk <mailto:blof@man.dtu.dk> www.ms.man.dtu.dk <http://www.ms.man.dtu.dk> http://www.maersk.com/innovation/leadingthroughinnovation/enerplan/ Please read about the ENERPLAN project here <http://www.maersk.com/innovation/leadingthroughinnovation/enerplan/>

2 3

Boost Parallel Graph Library: remove_vertex gives unexpected results.
by Alok Kumbhare 06 Apr '14

06 Apr '14

Hi All, i need some help with parallel boost graph library. In particular, i am trying to modify the structure of the graph (distributed adjacency list) after it is loaded. The code snippet is at http://pastebin.com/erizQ0Sf. The problem is that clear_vertex(v,g) and remove_vertex(v,g) does not seem to operate on the same vertex in the graph. Here is a sample graph in metis format: http://pastebin.com/qxy2w6aw (I use the default distribution for this example) The graph_viz output is available here for different scenarios: https://onedrive.live.com/redir?resid=C3CDB6EFBD31B4A8!20818&authkey=!AJqEF…<https://onedrive.live.com/redir?resid=C3CDB6EFBD31B4A8!20818&authkey=!AJqEF…> As you can see in the above figure: The first image is the original graph split into two partitions (mpirun -np 2 ./test) The second image is after clear_vertex is called for one of the vertices. Notice vertex "0". All the edges are removed as expected. The third image is after remove_vertex is called (which is called after clear_vertex, as mentioned in the documentation here: http://www.boost.org/doc/libs/1_55_0/libs/graph_parallel/doc/html/distribut…) Notice here that the vertex "2" is removed instead of vertex "0" even when using the same vertex descriptor for both calls. I tried putting synchronize(g) after each call, or at the end of both calls. but both gives the same results. Is this a bug or am i doing something wrong. Your help will be greatly appreciated. Thanks, Alok Kumbhare

1 0