- Boost-users - lists.boost.org

[crc] bug in boost::crc
by U.Mutlu 09 Jul '15

09 Jul '15

/* boost-crc-bug-demo.cpp Written by U.Mutlu on 2015-07-09-Th Compile: g++ -O2 -Wall -std=gnu++11 boost-crc-bug-demo.cpp Run: ./a.out Output: crc("The quick brown fox jumps over the lazy dog")=414fa339 crc("The quick brown fox ")=88b075e2 crc("The quick brown fox jumps over the lazy dog")=4ac56d0f ERROR See also: http://www.boost.org/doc/libs/1_58_0/libs/crc/crc.html#usage Conclusion: It doesn't do what it should and also advertises; ie. there's a bug */ #include <boost/crc.hpp> #include <boost/cstdint.hpp> #include <iostream> int main() { uint32_t expected; { const std::string sTxt = "The quick brown fox jumps over the lazy dog"; boost::crc_optimal<32, 0x04C11DB7, 0xFFFFFFFF, 0xFFFFFFFF, true, true> crc; crc.process_bytes(sTxt.data(), sTxt.size()); std::cout << "crc(\"" << sTxt << "\")=" << std::hex << crc.checksum() << std::endl; // save the result for the following test expected = crc.checksum(); } // test: doing the same as above, but now in 2 steps, ie. chunk- or blockwise: std::string sTxt; uint32_t result = 0xFFFFFFFF; for (size_t i = 0; i <= 1; ++i) { sTxt += !i ? "The quick brown fox " : "jumps over the lazy dog"; // using the special ctor for initial remainder stored in "result" boost::crc_optimal<32, 0x04C11DB7, 0xFFFFFFFF, 0xFFFFFFFF, true, true> crc(result); crc.process_bytes(sTxt.data(), sTxt.size()); std::cout << "crc(\"" << sTxt << "\")=" << std::hex << crc.checksum() << std::endl; result = crc.checksum(); } // eval: const std::string sRes = result == expected ? "SUCCESS" : "ERROR"; std::cout << sRes << std::endl; return 0; }

3 4

[Interprocess] posix robust mutex and EOWNERDEAD
by Malko 07 Jul '15

07 Jul '15

Hi, I lurked a bit and found this: http://boost.2283326.n4.nabble.com/boost-interprocess-gt-1-45-robust-mutexe… I didn't feel like necroposting, and it's /dev anyway, so allow me to ask here about updates on the matter. Is there anything, even if only "experimental" or "beta", that you have that would allow me to handle the EWOENERDEAD result? I'd rather use your code before putting my hands on your library, since it would be easier to let my manager (and his manager) deal with a "boost beta" rather than my personal modification to boost. If there is none, I would really need to modify your files for my project to work, and I would appreciate if you could confirm a couple of things for me. In http://stackoverflow.com/a/1179766/4598277 it is mentioned to modify two files: 1. posix/thread_helpers.hpp to set the attribute (first time ever I was happy to get an exception :D) 2. posix/mutex.hpp to handle the EOWNERDEAD return value Can you please confirm if this would be enough? It would seem so to me, but I have only studied parts of your code. Thank you for the assistance. -- View this message in context: http://boost.2283326.n4.nabble.com/Interprocess-posix-robust-mutex-and-EOWN… Sent from the Boost - Users mailing list archive at Nabble.com.

2 3

iterator over boost::tuple
by Uthpal Urubail 06 Jul '15

06 Jul '15

Experts, What is the best way to iterator over boost::tuple and return value? Example: For(int i=0;i<boost::tuples::length<T>::value;i++) { Boost_tuple_example.get<i>(); } Regards, UJ

5 4

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