July 2019 - Boost - lists.preview.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

Result of out_ptr review.
by Zach Laine 07 Aug '19

07 Aug '19

I've compiled the results of the reviews of out_ptr during its recent review. Unfortunately, out_ptr is NOT ACCEPTED, though many of the reviewers indicated interest in seeing it come back in some future form. I counted these formal reviews: Andrey Semashev: reject Louis Dionne: accept David Sankel: reject Phil Endecott: reject Glen Fernandes: reject Gavin Lambert: reject Thanks to all of the above reviewers, and to all those who contributed to the ongoing discussions surrounding out_ptr, even if they did not have time for a full review. Points against out_ptr raised during the review: - Many reviewers indicated their puzzlement that this library was proposed at all, since they had never seen enough calls to C APIs in their own code to motivate the need for out_ptr. - Some reviewers who did find the motivating cases of the library compelling, still said that they would prefer to write wrappers instead of using something like out_ptr. - Multiple reviewers want the library to provide error-reporting help (it currently does not). In particular, for c_func(out_ptr(p)), there was a concern about whether p is assigned a value, when c_func() returns a failure-status. - There was concern from several reviewers about the fact that out_ptr's types' dtors may throw, though this is only limited to the use of out_ptr with shared_ptr and similar smart pointers. In particular, non-unique_ptr uses will never throw in out_ptr's types' dtors, unless the user provides a throwing deleter. - Multiple reviewers disagreed with the use of template specialization as a customization mechanism. - There was widespread concern about the use of potentially UB-invoking tricks to get max performance out of the implementation. - Many reviewers wanted a more typical Boost tutorial introduction in the documentation. Now please permit me a digression. The library attempts to take a call that looks like this (simplest call possible): // CASE 0 foo * new_foo; TODO if (!create_foo(&new_foo)) { // etc. ... } And turn it into something as close as possible to this: // CASE 1 std::unique_ptr<foo> new_foo; if (!create_foo(new_foo)) { // etc. ... } out_ptr does a great job of this lexically: // CASE 2 std::unique_ptr<foo> new_foo; if (!create_foo(out_ptr(new_foo))) { // etc. ... } If you have not written thousands of lines of code that look like case 0, stop for a second and consider what it would be like to drop those thousands of raw pointers into your code, and how much you would like to replace them all with unique_ptrs. Now consider what it would take you to write all the wrapping functions necessary to make those thousands of calls look like case 1. You may make tooling to generate the wrappers, and that's time consuming. Writing it by hand is even more so. out_ptr also has the nice property that using it as I have above with unique_ptr does not change the meaning of the code, except to ensure that new_foo is guaranteed to be treated in a RAII manner. Thus we get increased exception safety, memory leak mitigation, etc. -- y'know, all that RAII stuff. If out_ptr is implemented well, case 2 should produce nearly identical object code to case 0, except that case 2 handles calling new_foo's dtor at the right time. Note that because of this, you have the same relationship to the C API in all three cases. That is, you need to check for the success value returned from create_foo(), and you need to know what create_foo()'s contract is in the face of errors -- did it write to new_foo or not? out_ptr is how you get from raw pointers to RAII ones, not how you solve all programming problems related to calling functions. Hopefully that motivates the use case for out_ptr, even if you don't need it in your own code. Hopefully that also allays concerns that out_ptr is not doing enough -- doing more is outside the library's scope. Now, on to exceptions in out_ptr's types' dtors. I heard a lot of discussion about this during the review. To me, concerns about what happens when an out_ptr or an inout_ptr throws in its dtor misses the point entirely, because it is concerned with fixing corner cases we should not even care to support. Instead of worrying about the semantics of exceptions in those kinds of situations, we should instead be asking why we want to support user code like this: ... } catch { create_foo(in_out_ptr(my_shared_ptr_to_a_foo)); ... } In other words, we don't really care about the dtor exceptions, unless: - there is an active exception already, and - we are also calling a C API to create a new object (a possible, but certainly atypical thing to do when handling an exception), and - we're catching this new object in a shared_ptr-like smart pointer that might throw on construction. Who writes code like that? Few people, perhaps none. It's not impossible to see code like that, but until there are well-motivated cases for this, maybe leave it for a later version of the library. In other words, the question should have been "Why support anything other than nothrow-constructible RAII types like unque_ptr?" Note that I find this argument compelling for the WG21-facing version of this work too. To summarize: I think the first four bullet points listed at the beginning of this post are, or could easily be made to be, irrelevant. So, that leaves some issues still outstanding: - figure out how to provide customization points (I'm actually fine with the current approach...), - eliminate the UB-dangerous code, or make it opt-in, - rework the tutorial portion of the docs, and - many assorted doc cleanups. That does not seem like an unreasonable amount of stuff to resolve in post-review acceptance readiness. I bring all this up because I do in fact hope that JeanHeyd brings this back for a future review, and I hope that my arguments here will convince some of you that this library is a useful thing to have around. I waited until now to say any of these things in an attempt to remain impartial during the review; I've been bothered by seeing previous review managers clearly represent a pro-acceptance position from the start. Thanks to JeanHeyd for his submission. A no-vote from this group is a tough thing, and I hope that the feedback he has received takes some of the sting out. Zach

6 5

[asio][coroutine] forbid_suspend blocks
by Vinícius dos Santos Oliveira 07 Aug '19

07 Aug '19

I've implemented a dumb linter using Python + clang API that allows you to mark certain blocks as “atomic in respect to coroutines” using C++11 attributes. Usage example follows: void f() { int yield; g(yield); [[bt::forbid_suspend]] { // Comment this call to make linter accept the code g(yield); t(); } } You can change bt::forbid_suspend to another identifier by tuning settings on the beginning of the script. The prefix forbid was inspired by Rust's linters[1] as you cannot disallow the linter from inside the forbid_suspend block. Some limitations follow: - A suspend point is identified by looking references to any id equals to yield in the last argument passed to function calls. It means that yield[ignored_ec] and alike will be correctly identified, but it needs to be named yield and it needs to be the last argument to the function call. - I haven't found a way to extract attributes related to COMPOUND_STMT nodes with clang API, so I manually look for token gaps and do a simple regex. It means you cannot use macros to [[bt::forbid_suspend]] as the macro won't be expanded. - You better call the script with '-x c++' and also ' -I/usr/lib/clang/5.0.1/include'. Like I've said in the beginning of the email, it's a *dumb* linter, which means it doesn't try to handle all cases. Therefore, I don't hope to do many changes to it or maintain it to work against newer releases of clang and I'm only uploading it to gist (not fullblow Github): < https://gist.github.com/vinipsmaker2/d930fbe5b7597432b021effe618da171>. It should also be easy to hack as it is very small. I'm releasing the linter under public domain. Enjoy. I have been using fibers in a daily basis on the last months of my job to solve networking problems on a gateway project. Some of the technologies I use are: - Boost.Asio and its spawn function. - A few custom synchronization primitives for the fibers (e.g. mutex, semaphore). - Eventually I'll have to write a custom spawn function that returns a joinable handle so I can kill the usage of a fiber::barrier in a few places. I've been using the linter for about a week already and looks fine. My use case are: - To prevent iterator invalidation in regions accessing shared variables. - To guarantee events order in algorithms that handle races (cannot yield while task YYY hasn't finished). The project I use it in is not an open source project, so I cannot talk much more about it. Also, I don't claim my solution is original. I wouldn't be surprised if the very same solution exists in the wild (please let me know if you know of a similar approach). This is not a new problem. It is know for some time. For instance, in P0171, Gor Nishanov noted this same problem: “In coroutines the suspend point is clearly marked with await, which tells the reader that something unusual happens in this function and allows the reader, for example, to confirm whether the lifetimes of the objects of interest align with the lifetime of the coroutine or not, whether some locks need to be acquired to protect some concurrently accessed data, and whether some locks need to be released before the execution reaches the suspend point.” — <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html>, 2015 However, the solution he presented was to manually examine whole blocks of code without help from the compiler. I argue that the solution he presented is as error-prone as manually looking for exit paths that don't free acquired resources in languages lacking RAII. And I've been spoiled too much by RAII. Furthermore, I take this comment of his with highly suspicious look: “Since we are on the subject of maintenance nightmares, we would like to offer a conjecture that the absence of the await in P0114 is a likely source of many maintenance nightmares. Without a syntactic marker to signal to the person reading the code that something funny is going on, it is impossible to tell whether the following code is correct or not” — http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html If I had to give a vote to the proposal he was defending or Chris' proposal, I'd probably have chosen Chris'. [1] https://doc.rust-lang.org/reference/attributes.html# lint-check-attributes -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 3

Making copyright holders easier to parse
by Giovanni Mascellani 07 Aug '19

07 Aug '19

Dear Boost developers, I am one of the Debian developers maintaining the Boost package in Debian. As part of packaging policy, we want the copyright status of each file in Debian packages to be documented, which includes at least the name of the copyright holders and the license of that particular file. As you can believe, this is rather complicated for Boost, since there are a lot of files with many copyright holders. I started to use the tool bcp, which among other things is able to collect such copyright information. My clone is available here[1]. However, bcp often is confused by the inconsistent style of how copyright holders are listed in different files, so it required a lot a manual fixing. For example, sometimes copyright years are written before the name, sometimes after, sometimes they're absent; names are sometimes separated by commas, sometimes by newlines, maybe even sometimes by nothing. Sometimes there are spelling mistakes or casing inconsistencies between names, or inconsistent institutions' names. Bcp has some complicated regular expression to overcame all these differences, but the result is brittle at its best. [1] https://salsa.debian.org/gio/boost-copyright Since I am doing this manual work anyway, I might as well update the Boost files so that their copyright headers are more consistent and easy to parse, and then I could submit you patches for having them fixed in the Boost official repositories. My question is: are you interested in this kind of patches? Of course I would still go through the ordinary patch submission procedure. I am just asking if this kind of patches would be well received or not. To better illustrate what I mean, let me consider a few examples (the chosen files are completely random); file libs/log/include/boost/log/exceptions.hpp currently has: > /* > * Copyright Andrey Semashev 2007 - 2015. > * Distributed under the Boost Software License, Version 1.0. > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ I might change this to: > /* > * Copyright: 2007-2015 Andrey Semashev > * License: Boost Software License, Version 1.0 > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ File libs/atomic/include/boost/atomic/fences.hpp has: > /* > * Distributed under the Boost Software License, Version 1.0. > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > * > * Copyright (c) 2011 Helge Bahmann > * Copyright (c) 2013 Tim Blechmann > * Copyright (c) 2014 Andrey Semashev > */ I might change this to: > /* > * Copyright: 2011 Helge Bahmann > * Copyright: 2013 Tim Blechmann > * Copyright: 2014 Andrey Semashev > * License: Boost Software License, Version 1.0 > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ I hope these examples illustrate my intention. I think that having more easily parsable copyright holders could be useful for Debian, for Boost and for Boost adopters which should properly care about the licensing of the libraries they use. Thank you, Giovanni. -- Giovanni Mascellani <g.mascellani(a)gmail.com> Postdoc researcher - Université Libre de Bruxelles

14 23

[release] 1.71.0 post-beta merges
by Michael Caisse 05 Aug '19

05 Aug '19

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> Thanks, -- The Boost Release Team

7 17

Norton blocking Appveyor?
by John Maddock 01 Aug '19

01 Aug '19

Hi all, I see that my browser is just started blocking ci.appveyor.com which is a bit of a problem for CI to say the least. Is anyone else seeing this? Any ideas whether it's justified or spurious? Thanks, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

Final Call for Submissions: International Conference on Information Society (i-Society 2019)
by International Conference on Information Society 29 Jul '19

29 Jul '19

If you are not able to see this mail, click http://r.confinfosoc.org/mk/mr/dNqT-1si6HE5qHDv5cV6nrZEGnVvH63myFIAZaMHhWb9… Final Call for Submissions: International Conference on Information Society (i-Society 2019) The i-Society is a global knowledge-enriched collaborative effort that has its roots from both academia and industry. The conference covers a wide spectrum of topics that relate to information society, which includes technical and non-technical research areas. Submission Instructions: * You can submit your extended abstract or paper online at [ http://www.i-society.eu/paper-submission/ ]( http://r.confinfosoc.org/mk/cl/f/cKABES_5mIGAo8Mgp-cuui5DCd9DYYIrOsBvLgtLLN… )or email it to papers(a)i-society.eu * You can submit your poster via email at posters(a)i-society.eu * You can submit your workshop or tutorial proposal at workshop(a)i-society.eu or tutorial(a)i-society.eu * You can submit your speaker's proposal at speakers-2019(a)i-society.eu [ Submit ]( http://r.confinfosoc.org/mk/cl/f/FhV5CG1-0Pk8UtOQVyS5RSUsGqCAVXq-AH1LIwQW9t… ) This email was sent to boost(a)lists.boost.org You received this email because you are registered with Infonomics Society [ Unsubscribe here ]( http://r.confinfosoc.org/mk/un/07f-n0ocPpExwtzrl_PeKAeTG4ctupFicTSTp-RuT97r… ) [ ]( http://r.confinfosoc.org/mk/cl/f/j-a-1n1z1XvvyX_L5iaFp6R3gGFhBceWdCdqP1QnZF… ) © 2019 Infonomics Society

2 1

MSVC 2019
by Cg K 27 Jul '19

27 Jul '19

I recently installed Visual Studio 2019 and then Boost and Quantlib. I tried to compile Quantlb with the precompiled 1.70 boost. I go the error message: LINK : fatal error LNK1104: cannot open file 'libboost_unit_test_framework-vc142-mt-gd-x64-1_70.lib' It appears that compatibility with Visual Studio/MSVC 2019 has not been worked out in 1.70 given its release date was so close to the release date of Visual Studio 2019. I also noted the the beta for 1.71 was closed. Wondering if the beta fixes this or is there a workaround or is this a user error?

7 9

RSS1/RSS2/ATOM + P2P
by Ggh 27 Jul '19

27 Jul '19

Dear All, I invite you all to a debate/brainstorming on implementing an RSS library for boost, as well as an RSS+p2p protocol on the application layer on the TCP/IP stack. I do not claim that RSS should have an implementation in boost, however I think it might be a good idea. Lots of activity on http/application layer of the web and perhaps we/boost developers should consider an RSS extention to boost of RSS/Atom, with P2P capabilities. As always, comments and critisism is velcome. Thank you, Cheers Greg Tell me, and I forget. Ask me, and I discover...

1 0

proposals
by VALERIU SMERICA 27 Jul '19

27 Jul '19

Hello. Is it possible to propose some data structures to be part of Boost that use code under the Apache 2.0 license? Are there any legal issues with this? I heard Apache 2.0 license was pretty permissive. Thanks.

2 1

[release] Boost 1.71.0 Beta 1
by Michael Caisse 26 Jul '19

26 Jul '19

Boost release 1.71.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.71.0.beta1.rc1/source/> The SHA256 checksums are as follows: 451adc4f199c73e995e541f38c4dbd51faf4ce0db15537136ffd5213a1be5e55 boost_1_71_0_b1_rc1.7z a93d7066fc1514995aec0e726532a219447dd39b0ffa7cb97ca5736f16b0488b boost_1_71_0_b1_rc1.tar.bz2 34743b80466463e0c1b7fc71b677f326bdc242fe0b87a9c1599b6f7ea6e5c0cb boost_1_71_0_b1_rc1.tar.gz 5cd448bddc8394469391306e0ccada0a8f88c5c6cf8ec775ddf8e56adef8bbc2 boost_1_71_0_b1_rc1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_71_0.html>. Note: Having some trouble getting the web page updated... check back with it soon. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

9 15

Boost proposals
by VALERIU SMERICA 26 Jul '19

26 Jul '19

Hello. Is it possible to propose some data structures to be part of Boost that use code under the Apache 2.0 license? Are there any legal issues with this? I heard Apache 2.0 license was pretty permissive. Thanks.

1 0

boost::serialization optional does not use boost::serialization::access
by Janek Kozicki 25 Jul '19

25 Jul '19

Hi, this simple program will not compile. The only way to make it work is to make a public default constructor. This defeats the purpose of boost::serialization::access. I tried to fix <boost/serialization/optional.hpp> but I couldn't get it to correctly call the access::construct(); Please help. // g++ -o serialize_optional /tmp/serialize_optional.cpp -lboost_serialization #include <fstream> #include <iostream> #include <boost/serialization/nvp.hpp> #include <boost/serialization/serialization.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/serialization/access.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/optional.hpp> #include <boost/optional.hpp> class Foo { public: Foo(int k) : i(k) {} friend std::ostream& operator<<(std::ostream& os, Foo const& foo) { return os << "Foo { " << foo.i << " }"; } private: Foo() : i(-1) {}; friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int){ #define N(a) BOOST_SERIALIZATION_NVP(a) ar & N(i); #undef N }; int i; }; int main() { using Data = boost::optional<Foo>; std::cout << "Boost version: " << BOOST_VERSION << "\n"; { auto f = Data(133); std::ofstream os("test.xml"); boost::archive::xml_oarchive oa(os); oa << boost::serialization::make_nvp("f", f); } { Data g; std::ifstream is("test.xml"); boost::archive::xml_iarchive ia(is); ia >> boost::serialization::make_nvp("f", g); std::cout << g.get() << "\n"; } } best regards Janek Kozicki

2 4

[gil] Missing doc/html/ files from Boost 1.70
by Mateusz Loskot 24 Jul '19

24 Jul '19

Hi, I'm following up this old report of mine [1] about missing GIL docs. Apparently, GIL documentation was not generated during the release process, so no files were copied wherever they should be. The documentation is missing from: - boost_1_70_0 source archives - https://www.boost.org/doc/libs/1_70_0/libs/gil/ Is it possible to fix the website at least, redirect it to valid URL? Can I fix it myself? How? [1] https://lists.boost.org/Archives/boost/2019/04/245985.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

[locale] Loss of precision (C4244) warnings in MSVC 64-bit build
by Kenneth Porter 24 Jul '19

24 Jul '19

Building with MSVC compilers for 64-bit results in several C4244 warnings in api.hpp, due to passing the difference of two pointers (ptrdiff_t) to Win APIs expecting an int. Patch here: <https://github.com/boostorg/locale/issues/42> Using this command with the recent 1.71.0 beta: call .\bootstrap.bat --without-python .\b2 --without-python toolset=msvc-14.2,msvc-14.0,msvc-12.0,msvc-10.0 runtime-link=shared,static address-model=32,64

2 1

[release] Boost 1.71.0 Beta 1 - déjà vu
by Michael Caisse 23 Jul '19

23 Jul '19

Note: The previous email announcement still had the rc1 tag in the filenames. This version of beta1 is identical in content to beta1 rc1. Boost release 1.71.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.71.0.beta1/source/> The SHA256 checksums are as follows: 451adc4f199c73e995e541f38c4dbd51faf4ce0db15537136ffd5213a1be5e55 boost_1_71_0_b1.7z a93d7066fc1514995aec0e726532a219447dd39b0ffa7cb97ca5736f16b0488b boost_1_71_0_b1.tar.bz2 34743b80466463e0c1b7fc71b677f326bdc242fe0b87a9c1599b6f7ea6e5c0cb boost_1_71_0_b1.tar.gz 5cd448bddc8394469391306e0ccada0a8f88c5c6cf8ec775ddf8e56adef8bbc2 boost_1_71_0_b1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_71_0.html>. Note: Having some trouble getting the web page updated... check back with it soon. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 1

[BOOST] Boost fusion testcase fails with llvm and gcc when optimization enabled
by Jaydeep Chauhan 22 Jul '19

22 Jul '19

Hi Devs, consider below boost testcase, boost_1_70_0/libs/fusion/test/functional/invoke.cpp when compiles with optimization enabled, $g++ -O2 -I./boost_1_70_0 boost_1_70_0/libs/fusion/test/functional/invoke.cpp $./a.out ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(391): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::vector<>]' ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(401): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_d_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::vector<>]' ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(391): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::list<>]' ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(401): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_d_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::list<>]' 4 errors detected. And When compiled without any optimization $g++ -O0 -I./boost_1_70_0 boost_1_70_0/libs/fusion/test/functional/invoke.cpp $./a.out No errors detected. $g++ --version Target: x86_64-pc-linux-gnu Configured with: ../gcc-9.1.0/configure -- --enable-languages=c,c++ --disable-libquadmath --disable-libquadmath-support --disable-werror --disable-bootstrap --enable-gold Thread model: posix gcc version 9.1.0 (GCC) Here we demonstrated the test case with g++ but same can be seen with clang++. When analyzed further we have seen that this is [ boost_1_70_0/boost/fusion/functional/invocation/invoke.hpp:139 ] trying to return local address, which is undefined behavior. And that lead to above test-case failure. So either we have to modify test-case to pass as reference or disable it.But before going ahead like to know your thought/suggestions? Thanks, Jaydeep

1 0

Innocent but annoying warning in Boost QVM library
by Luigi Castelli 19 Jul '19

19 Jul '19

Hi Emil and all, when compiling Boost QVM, compilation succeeds but I get this warning: filename: quat_operations.hppwarning: Declaration shadows a typedef in function 'boost::qvm::axis_angle' A declaration in line 1438 shadows one in line 1414 Could this be solved for the next update?Thanks - Luigi

2 1

Boost log to limit log file maximum file size
by JH 19 Jul '19

19 Jul '19

H Andrey and all, Can the log file be configured to set up the file size cap, when the log file reaches to the maximum file size, it deletes it and starts a new log file not rotates it? Thank you. - jupiter

2 1

Lambda testcase fails when optimization enabled in gcc and llvm
by navya deepika garakapati 19 Jul '19

19 Jul '19

Hi Devs, consider below reduced testcase from boost lamda. $cat result_of_tests.cpp #include <boost/lambda/lambda.hpp> #include <stdio.h> template<class A, class F> typename boost::result_of<F(A)>::type apply1(F f, A b) { return f(b); } using namespace boost::lambda; int main(int, char *[]) { int one = 1; int d= (apply1<int>(_1 ,one) == 1); printf("\n%d\n",d); return 0; } when compiled with optimization O2 $g++ result_of_tests.cpp -I ./boost_1_70_0 -O2 $./a.out 0 And,when we compile same testcase with O0 $g++ result_of_tests.cpp -I ./boost_1_70_0 -O0 $./a.out 1 The above testcases is demonstrated with g++ compiler but behavior is same on clang as well. so we thought that this may be boost testcase issue. When we replace , int d= (apply1<int>(_1 ,one) == 1); with int d= (apply1<int&>(_1 ,one) == 1); testcase gives correct result with or without optimization. Wanted to confirm here,is it valid testcase or we have to modify testcase as per above? Thanks, Navya

3 5

Review request for LEAF, review manager needed
by Emil Dotchevski 19 Jul '19

19 Jul '19

I'm requesting a formal review for LEAF, a C++11 error-handling library: https://zajo.github.io/leaf. Features: * Header-only, no dependencies. * No dynamic memory allocations. * Compatible with std::error_code, errno and any other error code type. * Can be used with or without exception handling. LEAF comes complete with its own result<T> type, but it is compatible with any other type with value-or-error variant semantics (like outcome::result<T>) as long as .error() returns a std::error_code. https://travis-ci.org/zajo/leaf https://ci.appveyor.com/project/zajo/leaf

3 2

Re: [boost] [release] 1.71.0 closed for Beta
by Kenneth Porter 19 Jul '19

19 Jul '19

I'm seeing the following block of warnings repeated with several MSVC compiler versions. I'd suggest changing int to ptrdiff_t or size_t for the target type. f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(149): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(153): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(153): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(170): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(245): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(249): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data My build command: call .\bootstrap.bat --without-python .\b2 --without-python toolset=msvc-14.2,msvc-14.0,msvc-12.0,msvc-10.0 runtime-link=shared,static address-model=32,64

1 0

[release] 1.71.0 closed for Beta
by Michael Caisse 19 Jul '19

19 Jul '19

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_71_0.q…> Thanks, -- The Boost Release Team

5 8

Any sample code to configure boost log for syslog?
by JH 18 Jul '19

18 Jul '19

Hi, I am using boost log to write log file in the disk of the desktop, but for an embedded system application where the NAND flash is used, to prolong the flash service life time, I try not to write log files in flash, but use journalctl to view the log in RAM. Are there any simple example to configure boost log for syslog? Thank you. - jh

2 2

Something off my chest about Boost
by Maarten Verhage 18 Jul '19

18 Jul '19

Dear Boost people, Sorry but I need to get something off my chest regarding the Boost culture. To start of with something nice: I’m convinced Boost provides really useful facilities for C++ and some of them even make it into the standard C++ library. I do believe I can also contribute in a reasonable way. But the terse documentation keeps me from advancing. How it is currently stated on https://www.boost.org/users/faq.html “What about documentation? A very simple library might be accepted with only a well commented header file. For more substantial libraries, some form of documentation is certainly going to be expected. HTML is the preferred form.” To make Boost more accessible to people I believe Boost should ask more on this from current and new library authors. Speaking for myself. I think the first bits to get started with a library are on a sufficient level. You know the tutorial and the example code. But I get lost when I want to use the library for my own application domain. Then I do need library facilities not covered in the example code and sometimes the documentation mentions only the syntax. As I would imagine the library author working on his/her library judging whether to add a facility or not. Finally decided to add something: *the thought/motivation that goes along with that*, that would be so valuable for me to read that in the documentation!! Yes, I’m annoyed that I cannot read that in the documentation. Another issue is when example code introduces three or more facilities at once. Then it is very hard for me to see how these bits relate to each other to make it useful for myself. Ok, a few examples for what I would like to ask the Boost community to demand from the library authors: 1) In general, for the classes/functions where the user should directly deal with documentation like cppreference.com. So, with function prototypes showing the argument- and return types and a complete list of members along with what they do. 2) Specifically for Spirit X3, a part on Parser Directives: https://www.boost.org/doc/libs/develop/libs/spirit/doc/x3/html/spirit_x3/qu… I would very much like that the reason why each directive is added along with a minimal example that shows how to use just that directive. Anyway, I hope people are also interested to discus documentation policies on this mailing list. I do believe it is important. Best regards, Maarten Verhage

10 17