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

boost.test fails to zip custom datasets
by Georgios Sermaidis 08 Dec '17

08 Dec '17

I am trying to understand how to use datasets with the boost.test library. I am following the documentation here <http://www.boost.org/doc/libs/1_65_1/libs/test/doc/html/boost_test/tests_or…> and have created my dataset as follows: namespace bdata = boost::unit_test::data; struct test_set { class iterator { int m_a; public: iterator() : m_a(0){} void operator++() { ++m_a; } int operator*() const { return m_a; } }; using sample = int; enum {arity = 1}; auto begin() const { return iterator{}; } bdata::size_t size() const { return 5; // let's assume only 5 numbers } }; namespace boost { namespace unit_test { namespace data { namespace monomorphic { template <> struct is_dataset<test_set> : std::true_type{}; }}}} which is very simple and iterates numbers from 0 to 4. The following simple test compiles and runs just fine: // this works as expected and prints 0, 1, 2, 3, 4 BOOST_DATA_TEST_CASE( example_test1, test_set(), my_datum) { std::cout << my_datum << std::endl; } However, when I try to zip <http://www.boost.org/doc/libs/1_65_1/libs/test/doc/html/boost_test/tests_or…> two such datasets it fails to compile (Apple LLVM version 9.0.0 (clang-900.0.38)): // error: invalid operands to binary expression ('typename data::result_of::make<test_set>::type' (aka 'test_set') and 'test_set') test_set() ^ test_set(), // ~~~~~~~~~~~^~~~~~~~~~~~~ BOOST_DATA_TEST_CASE( example_test2, test_set() ^ test_set(), my_datum1, my_datum2) { std::cout << my_datum1 << " " << my_datum2 << std::endl; } Is what I am trying to do legal? If so, what is the correct way to achieve it? Thank you for your help! Live code here <https://wandbox.org/permlink/6CI286mynvVCjQdW>

2 2

Easy install doesn't
by Jean-Louis Leroy 07 Dec '17

07 Dec '17

I downloaded the current version of boost from here: http://www.boost.org/users/download/ (the Unix tgz) Then I religiously followed these instructions: http://www.boost.org/doc/libs/1_61_0/more/getting_started/unix-variants.htm… It didn't install much of anything useful...just stuff in /usr/local/share/boost-build, apparently the build system. No headers were installed, no libs were built or installed... I tried to install from debian packages and that failed miserably too but that's another story... Help please?

3 2

[iostreams] file_descriptor doesn't retry on EINTR
by David Roberts 30 Nov '17

30 Nov '17

Hi, I have found that the file_descriptor class in Boost.Iostreams does not retry on EINTR. The relevant code is in libs/iostreams/src/file_descriptor.cpp. A bug was raised for this 7 years ago: https://svn.boost.org/trac10/ticket/4913 <https://svn.boost.org/trac10/ticket/4913> There is a patch attached to that bug that makes the file_descriptor_impl::read method retry on EINTR. If something like this were implemented then something similar should also be done to retry in the file_descriptor_impl::write method. I could have a go at submitting a PR to make both the read and write methods retry if interrupted. But before I do this, is there any other history I should be aware of, like a good reason why EINTR is not currently handled? Many thanks, David

2 1

boost::asio::buffer bug with string literal
by Martijn Otto 29 Nov '17

29 Nov '17

When using boost::asio::buffer with a string literal the terminating null character is included in the buffer size, leading to bugs like accidentally sending out a null character. We could fix this by adding something like this to buffer.hpp: /// Create a new non-modifiable buffer that represents the given character array. /** * @returns A const_buffer value equivalent to: * @code const_buffer( * static_cast<const void*>(data), * (N - 1) * sizeof(char)); @endcode */ template <std::size_t N> inline BOOST_ASIO_CONST_BUFFER buffer( const char (&data)[N]) BOOST_ASIO_NOEXCEPT { return BOOST_ASIO_CONST_BUFFER(data, (N - 1) * sizeof(char)); } But this might cause trouble when using a const char array that is not null-terminated, since we then basically drop the last character. Would this be the best approach?

3 6

[Spirit.Qi] failing to parse IP address octets
by Michael Powell 27 Nov '17

27 Nov '17

Hello, I've got the following parsers which are failing to find the correct attributes. I tried to parse in terms of uint_parser<uint8_t, 10, 1, 3>() at first, but this was not working properly. So I tried the following: _octet_rule = lexeme[ char_('0') | (char_('1') >> -(digit >> -digit)) | (char_('2') >> -((char_('0', '4') >> -(digit)) | (char_('5') >> -(char_('0', '5'))) | char_('6', '9') ) ) | (char_('3', '9') >> -digit) ]; Which is presently failing to find all three digits in the "20\d"-"24\d" use case. Octet itself parses correctly when I use this rule: _octet_rule >> !(char_); My octet test cases verify the entire range of 0-255 successfully, as well as the following invalid cases: VerifyOctet(-1, invalid_); VerifyOctet(1990, invalid_); VerifyOctet(2550, invalid_); VerifyOctet("255.", invalid_); VerifyOctet(256, invalid_); VerifyOctet(999, invalid_); VerifyOctet("abc", invalid_); VerifyOctet(123.456, invalid_); Converted to corresponding string, i.e. "1990" or "123.456". But when I combine that into the IP address rule, the test results occur: _octet_rule >> repeat(3)[char_('.') >> _octet_rule]; And the test results: CHECK_THAT( y, Equals(x) ) with expansion: "145.23.183.47" equals: "145.231.183.47" with message: Verifying address >>> 145.231.183.47 <<< FAILED: CHECK_THAT( y, Equals(x) ) with expansion: "189.21.29.11" equals: "189.211.29.11" with message: Verifying address >>> 189.211.29.11 <<< FAILED: CHECK_THAT( y, Equals(x) ) with expansion: "90.60.32.24" equals: "90.60.32.246" with message: Verifying address >>> 90.60.32.246 <<< FAILED: CHECK_THAT( y, Equals(x) ) with expansion: "22.59.144.140" equals: "223.59.144.140" with message: Verifying address >>> 223.59.144.140 <<< IP address test data is randomly generated, or combinatorially if I wanted to wait for all 4.3B or so test cases. However, I figure that as long as the Octet rule is working, it is reasonable to expect the Address rule may also work. Not sure why those last digits are being dropped, however. Or how the 1's can succeed where the 2's are failing. Any suggestions, Spirit folks? Thanks! Cheers, Michael Powell

1 3

[serialization] property_tree::ptree bpta back-end, json, forward (upward) compatibility
by Sergey Spiridonov 27 Nov '17

27 Nov '17

Hi Current binary, text and xml archive back-ends allow to implement backward compatibility. This means that it is possible to read old serialization files with the new version of the serialization code, with the help of the version of the class which is stored in archive itself. Unfortunately forward compatibility is not possible to implement with the existing archive backends. Suppose we have class A with one field. struct A { template<class Archive> inline void serialize(Archive & ar, const unsigned int version ) { ar & BOOST_SERIALIZATION_NVP(field); } int field; }; Later we want to add a new field2. To be able to load the previously created file we need can use versioning. struct A { template<class Archive> inline void serialize(Archive & ar, const unsigned int version ) { ar & BOOST_SERIALIZATION_NVP(field); if(version > 0) { ar & BOOST_SERIALIZATION_NVP(field2); } } int field; int field2; }; BOOST_CLASS_VERSION(A, 1) But if we want the opposite, to load the old class from the file which was created from the new class (for example, if we use serialization to communicate between new and old version of application on the network), existing backends will fail. Why? The reason is that they expect certain field in certain order and do not allow unexpected unknown fields. Although with text and binary backend it is difficult to do, because field names are not stored, but xml backend has names for every field, so it can simply skip unknown fields. Unfortunately this is not implemented. I created [1] simple experimental archive which allows forward(upward) compatibility. It stores data in boost::property_tree::ptree (instead of std::stream), which, in turn, can be saved to json, if necessary. If the file which is loaded, has additional unknown fields (from future version), they will be ignored. [1] https://github.com/sena73/ptree_archive Intermediate storage of data in ptree has its advantages and disadvantages. Of course, this slows down things and requires more memory. On other hand, it allows to get upward compatibility automatically easily and even to process data before (or without) loading it into the target class. Also we get json and info storage for free. With little modification xml backend from property_tree can be used. Sure, it must be possible to create a version of boost::archive::xml which will be also capable to keep upward compatibility without necessity to load things into the property_tree first. Binary and text archives must be extended with field names to allow field skipping. -- Best regards, Sergey Spiridonov

1 1

[release] Boost 1.66.0 Beta 1
by Daniel James 24 Nov '17

24 Nov '17

Boost release 1.66.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/> The SHA256 checksums are as follows: e7b23e638e8c3a9da1512439385b04850829cea7bd56d8398677c096857d830b boost_1_66_0_b1.7z 5d0405eb73bd609ebcd54bbc96d4f1e2d97c51b96c4703706695ddd94f942d6b boost_1_66_0_b1.tar.bz2 f0f455e39bc47b2b670a17cb221687506e9a22dc478956d3d8aabb9cb835a7dc boost_1_66_0_b1.tar.gz 694c8b9e902b7981670bce166f675f3875c19326936db51aabd98d2ddfea9b45 boost_1_66_0_b1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_66_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

3 4

how to build boost binary libraries for GCC in windows 10
by Renfan Luo 23 Nov '17

23 Nov '17

Hi All As VS supports OpenMP2.0 only, I have to use GCC instead for my project with parallelisation in coding. I have downloaded Cygwin and installed the GCC 6.4.0 then updated it to the latest version 5.5.0 on my windows 10. All those binary libraries I built up in VS 2017, I guess, cannot be usable for GCC, so it may be necessary to rebuild them for boost 1.65.1 for GCC. Could you guys show me how to build them? Cheers Renfan

2 4

function template argument deduction with std::tuple
by Ireneusz Szcześniak 23 Nov '17

23 Nov '17

Hi, I have a problem related to function template argument deduction with std::tuple (with boost::tuple too). I attach a file with the complete source you can compile. Below I describe the code. I have a template function declaration: > template <typename T> > auto > get_cost(const T &); Then I define my template types: > template <typename Graph> > using Vertex = typename Graph::vertex_descriptor; > > template <typename Graph> > using Label = std::tuple<Vertex<Graph>>; I define the specialization of the get_cost function for the Label type: > template <typename Graph> > auto > get_cost(const Label<Graph> &l) > { > return std::get<0>(l); > } I can define alright a variable of type Label: > struct graph > { > using vertex_descriptor = unsigned; > }; > > Label<graph> l; But I cannot use the templated function: > get_cost(l); I get this error: > error: use of 'auto get_cost(const T&) [with T = > std::tuple<unsigned int>]' before deduction of 'auto' I got this error with GCC HEAD 8.0.0 20171113 and Clang HEAD 6.0.0 (I used wandbox.org) Some other type definitions and their specializations of the get_cost function compile. For a struct derived from the std::tuple: > template <typename Graph> > struct Label1: std::tuple<Vertex<Graph>> > { > }; > > template <typename Graph> > auto > get_cost(const Label1<Graph> &l) > { > return std::get<0>(l); > } For a member of type std::tuple: > template <typename Graph> > struct Label2 > { > std::tuple<Vertex<Graph>> t; > }; > > template <typename Graph> > auto > get_cost(const Label2<Graph> &l) > { > return std::get<0>(l.t); > } For a member of type Vertex<Graph>: > template <typename Graph> > struct Label3 > { > Vertex<Graph> m_v; > }; > > template <typename Graph> > auto > get_cost(const Label3<Graph> &l) > { > return l.m_v; > } I would like to use the Label type, i.e., because it has the constructor and operators already defined, which I need. I would appreciate it if someone could explain what is going wrong here. Best, Irek

2 6

Building b2 --prefix include directory not quite
by Michael Powell 22 Nov '17

22 Nov '17

Hello, So the B2 help indicates that the include directory should be whatever "<prefix>/include" is. So, I'm setting my prefix accordingly, something like, "/path/to/installed/boost-1.65.1", however, the include directory ends up being something a little more like this: "/path/to/installed/boost-1.65.1/include/boost-1_65_1". This looks like a bug to me. Can I set the --includedir myself and correct this during my build? Thank you... Cheers, Michael Powell

1 0