July 2015 - Boost-users - lists.boost.org

Boost python and python sets
by Will Hall 06 Jul '15

06 Jul '15

Hi, I'm struggling to find a way to support python sets with boost. The Python API is well defined, so am unable to switch to Python list type. The API needs to support Python sets for both input and output values. I have output values (from C++ to Python) working as follows with to_python namespace bp = boost::python; template<class T> struct to_python; template<class T> struct to_python<std::set<T> > { to_python() { bp::to_python_converter< std::set<T>, to_python< std::set<T> > >(); } static PyObject* convert(const std::set<T>& set) { bp::list values; for(typename std::set<T>::const_iterator iter=set.begin(); iter!=set.end(); ++iter) { values.append(bp::object(*iter)); } PyObject* result = PySet_New(values.ptr()); return result; } static const PyTypeObject* get_pytype() { return &PySet_Type; } }; BOOST_PYTHON_MODULE(helpers) { to_python< std::set<int> >(); bp:class_<MyClass>() // Define constructor with const std::set& arg // Define method that returns const std::set& arg } But I have no idea how to write an equivalent "from_python" to convert Python set to std::set. Any help would be very appreciated!

1 0

{Serialization] Deserialization of const references
by Mccall, Kurt E. (JSC-EG411) 06 Jul '15

06 Jul '15

As near as I can tell from the documentation http://www.boost.org/doc/libs/1_57_0/libs/serialization/doc/serialization.h… , the following is the way to handle const reference members, which are initialized in the constructor. Serialization seems to be working, from an inspection of the resulting XML file, but after deserialization, the values in the object given by the const reference are wrong and are all zero. Here is my question: Is load_construct_data() below correct? It looks like it is initializing the constant reference from a temporary, but I'm doing the same thing as the example in the documentation. class MyClass1 { friend boost::serialization::access; … }; class MyClass2 { friend boost::serialization::access; const MyClass1 & mc1_; MyClass2 ( const MyClass1 &mc1) : mc1_(mc1) { } ; }; namespace boost { namespace serialization { template<class Archive> inline void save_construct_data( Archive &ar, const MyClass2 *t, const unsigned int file_version) { // mc1_ is a reference and requires special handling -- save it // as a pointer const MyClass1 *mc1 = &t->mc1_ ; ar << boost::serialization::make_nvp("mc1_", mc1); } template<class Archive> inline void load_construct_data( Archive &ar, MyClass2* t, const unsigned int file_version) { MyClass1 *mc1; ar >> boost::serialization::make_nvp("mc1_", mc1); // NOTE: IS THIS INITIALIZING THE REFERENCE FROM A TEMPORARY? ::new(t) MyClass2(*mc1); } Thanks, Kurt

1 0

Problems to use Boost Graph
by Oodini 04 Jul '15

04 Jul '15

Hello, I am trying to understand the boost::dijkstra_shortest_paths() function. I don't understand the second and third arguments. The documentation says they're supposed to be properties map : OUT: predecessor_map(PredecessorMap p_map) The predecessor map records the edges in the shortest path tree, the tree computed by the traversal of the graph. Upon completion of the algorithm, the edges (p[u],u) for all u in V are in the tree. The shortest path from vertex s to each vertex v in the graph consists of the vertices v, p[v], p[p[v]], and so on until s is reached, in reverse order. The tree is not guaranteed to be a minimum spanning tree. If p[u] = u then u is either the source vertex or a vertex that is not reachable from the source. The PredecessorMap type must be a Read/Write Property Map whose key and value types are the same as the vertex descriptor type of the graph. but that doesn't work. I have to use an iterator on the properties map, by using : boost::make_iterator_property_map(pred_map.begin(),vertex_index) Does the documentation need reviewers ?

3 4

Re: [Boost-users] [boost] Boost.DLL formal review is ongoing
by Ralf Globisch 03 Jul '15

03 Jul '15

Hi, Firstly, thanks Anthony for submitting this useful library to boost, and to Vladimir for managing the review. - Should the library be accepted? Yes. I had been meaning to test the library for some time, and with the review reminder finally made some time to do so. My vote of yes is based on my (limited) positive experience with the library, as well as having followed past related discussions on the mailing list, in which many questions are addressed. (http://lists.boost.org/Archives/boost/2014/09/216650.php) I think boost.DLL should be accepted unless someone has a serious/valid reservation as to why this library should not to be accepted. - How useful is it? Very useful. It enabled me to add a test-plugin mechanism to an existing application (Windows and Linux) in a matter of minutes. - What's your evaluation of - Design Looks good to me. Simple to use, with good integration into rest of boost (e.g. file_system). I like the fact that the library is header only and minimal effort was required to integrate plug-in like functionality into an existing application. - Implementation I'm not knowledgeable enough to comment on this. - Documentations Good, the tutorials made it fairly easy to get going and covered my common usage scenarios Code is well commented. - How much effort did you put into your evaluation? About three hours worth of effort, reading through documentation and source code, and using library to create a very simple plug-in mechanism in an existing application. Tested basic plug-in functionality on Windows and Linux. - Did you attempt to use the library? On what systems and compilers? Yes -Linux Ubuntu 14.10 with gcc 4.9.1 with boost 1.57 -Window 7 64-bit with VS 2013 community edition with boost 1.58. Initially made the mistake of not checking the boost version (which had been 1.53 and caused lots of compilation errors.) Minor typo in documentation: Just above the "Full Sources" for tutorial 4 "If we want o make a traditional" should be "If we want to make a traditional" Regards, Ralf >>> Vladimir Prus <vladimir.prus(a)gmail.com> 07/03/15 3:52 PM >>> The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable. The summary of the library features and review checklists are reproduced below. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email.

1 0

[asio] async udp socket latency
by Andrew Hundt 03 Jul '15

03 Jul '15

I'm having difficulty with latency when running an async asio udp socket. I don't have the same problems with an identical application that uses synchronous udp. I'm communicating with a physical device which permits a maximum 5ms latency for each UDP packet, and I'm currently getting a latency of 8ms with a std dev of 0.065ms which is surprisingly precise. I'm on Mac OS X 10.10.4 with Xcode 6.3.2 (6D2105). Here are some of the key details about this problem: - Sync UDP test program - works, staying under 5ms latency 100% of the time for over an hour - Code - main file KukaFRIClientDataTest.cpp <https://github.com/ahundt/grl/blob/master/test/KukaFRIClientDataTest.cpp> - UDP socket communication class KukaFriClientData.hpp <https://github.com/ahundt/grl/blob/master/include/grl/KukaFriClientData.hpp> - Key lines - calls socket.receive_from() then socket.send() at the lowest level. - receive_from call <https://github.com/ahundt/grl/blob/master/include/grl/KukaFriClientData.hpp…> - send call <https://github.com/ahundt/grl/blob/master/include/grl/KukaFriClientData.hpp…> - Async UDP test program - buggy, 8ms w/ 0.065 ms std dev, continuously high latency - Code - main file KukaFRITest.cpp <https://github.com/ahundt/grl/blob/master/test/KukaFRITest.cpp> - High level wrapper class KukaFRIThreadSeparator.hpp <https://github.com/ahundt/grl/blob/master/include/grl/KukaFRIThreadSeparato…> - Low level wrapper class KukaFRI.hpp <https://github.com/ahundt/grl/blob/master/include/grl/KukaFRI.hpp> . - Key lines - calls socket_.async_receive_from() then that handler calls socket_.async_send_to(), which calls the final callback with the results. - async_receive_from call <https://github.com/ahundt/grl/blob/master/include/grl/KukaFRI.hpp#L374> - async_send_to_call <https://github.com/ahundt/grl/blob/master/include/grl/KukaFRI.hpp#L432> Does anyone have insight into why this latency issue may be occurring in the Async UDP version? Thanks. Cheers! Andrew Hundt

5 7

Re: [Boost-users] Boost-users Digest, Vol 4182, Issue 1
by Carl Wallace 02 Jul '15

02 Jul '15

>Date: Wed, 1 Jul 2015 15:04:34 +0900 >From: Kohei Takahashi <flast(a)flast.jp> >To: boost-users(a)lists.boost.org >Subject: Re: [Boost-users] Boost-users Digest, Vol 4181, Issue 1 > >>> Can I get (minimal) reproducible code or more detailed error log? >>> >>> Best, >>> Kihei >> This stripped down code snip is enough to trigger the error when the >>1.58 >> code is in place and compiles fine when the code from 1.54 is >>substituted >> in the place I indicating initially. This code is not intended to do >> anything and I have not run it. I can send the original error message if >> you like too. Will send that privately if you want it. >It should be fixed by https://github.com/boostorg/fusion/pull/87. It worked. Thanks.

1 0

Boost 1.58 and Intel Compiler 15
by Matthieu Brucher 02 Jul '15

02 Jul '15

Hi, Has any one worked with the latest Intel compiler on Linux? I'm hit with some Spirit/Fusion issues that don't arise with gcc 4.8.2 or clang 3.6.0. Quite difficult to diminish the number of lines in my example case, as the errors are different between in project and out of project... Cheers, Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher Music band: http://liliejay.com/

1 1

Re: [Boost-users] Boost-users Digest, Vol 4181, Issue 1
by Carl Wallace 01 Jul '15

01 Jul '15

> >Message: 7 >Date: Tue, 30 Jun 2015 11:08:50 +0900 >From: Kohei Takahashi <flast(a)flast.jp> >To: boost-users(a)lists.boost.org >Subject: Re: [Boost-users] fusion error when compiling graphviz code > using VC2010 >Message-ID: <5591FA32.6070802(a)flast.jp> >Content-Type: text/plain; charset="utf-8" > >Hi Carl, > >On 2015/06/29 20:36, Carl Wallace wrote: >> We have been using Boost's graphviz support for several years and have >> upgraded through a few versions of Boost with no issues in some long >> stable code. However, when we moved to 1.58 our Windows build broke. We >> are still using VC2010, with plans to move to 2015 in the >>not-too-distant >> future. We have not yet tried 1.58 in VC2015. The error message is very >> large but emanates from here: >Can I get (minimal) reproducible code or more detailed error log? > >Best, >Kihei This stripped down code snip is enough to trigger the error when the 1.58 code is in place and compiles fine when the code from 1.54 is substituted in the place I indicating initially. This code is not intended to do anything and I have not run it. I can send the original error message if you like too. Will send that privately if you want it. #include <boost/graph/breadth_first_search.hpp> #include <boost/graph/visitors.hpp> #include <boost/graph/graphviz.hpp> using namespace boost; template <class Name, class ColorMap> class label_writer2 { public: label_writer2(Name _name, ColorMap _color) : name(_name), color(_color) {} template <class VertexOrEdge> void operator()(std::ostream& out, const VertexOrEdge& v) const { } private: Name name; ColorMap color; }; struct VertexProps { }; typedef adjacency_list < vecS, vecS, bidirectionalS, VertexProps> graph_t; typedef property_map<graph_t, std::string VertexProps::*>::type name_map_t; int _tmain(int argc, char* argv[]) { std::ostringstream oss; graph_t m_graph; name_map_t m_nameMap; two_bit_color_map<property_map<graph_t, vertex_index_t>::const_type>color_map(num_vertices(m_graph), get(vertex_index, m_graph)); boost::write_graphviz(oss, m_graph, label_writer2<name_map_t, two_bit_color_map<property_map<graph_t, vertex_index_t>::const_type> >(m_nameMap, color_map)); return 0; }

2 1

boost log linking
by Lane 01 Jul '15

01 Jul '15

I'm working with boost log examples (v1.55) of trivial logging and having issues linking against these libraries. I'm receiving these errors. undefined reference to `boost::log::v2s_mt_posix::core::get()' undefined reference to `boost::log::v2s_mt_posix::core::set_filter(boost::log::v2s_mt_posix::filter const&)' In function `main': undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()' undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()' undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()' undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()' undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()' more undefined references to `boost::log::v2s_mt_posix::trivial::logger::get()' follow What I don't understand is that I have the correct paths to where the shared libs are located in my make file (-L/usr/lib64) and also included the libs (-lboost_log -lboost_setup). I have these boost libs on my system. /usr/lib64/libboost_log_setup-mt.so /usr/lib64/libboost_log-mt.so /usr/lib64/libboost_log_setup.so /usr/lib64/libboost_log.so /usr/lib64/libboost_log_setup.so.1.55.0 /usr/lib64/libboost_log.so.1.55.0 /usr/lib32/libboost_log_setup-mt.so /usr/lib32/libboost_log-mt.so /usr/lib32/libboost_log_setup.so /usr/lib32/libboost_log.so /usr/lib32/libboost_log_setup.so.1.55.0 /usr/lib32/libboost_log.so.1.55.0 Anyone see what I'm doing wrong?

1 0