- Boost-users - lists.boost.org

Boost ASIO HTTP Server example design question
by TomJordan 12 Aug '19

12 Aug '19

Hi, I'm just starting to use ASIO. I have been reading the C++11 HTTP Server example at https://www.boost.org/doc/libs/1_70_0/doc/html/boost_asio/example/cpp11/htt… and want to make sure I understand use of shared_ptr in this example, because I didn't notice any explanation in the documentation. The connection class inherits from std::enable_shared_from_this<connection>, and is then passed in a shared_ptr (the captured 'self') to the handler function registered with the async_read_some in connection::do_read(). Is this approach, and the related design decsision that the server creates a shared_ptr to a new connection in its server::do_accept() function, taken simply in order to ensure that the connection object is kept alive for as long as any asynchronous read/write operation requires it? So is it implying that if the connection was NOT kept alive by a shared_ptr (i.e., was instead created by the server and stored by value in a std container) something bad could and likely would happen at some point, most likely due to the handler being called on an object that no longer exists? This might be when a boost::asio::error::operation_aborted is reported by the handler, when a current async operation is cancelled during the server/connection_manager shutdown process as a result of closing the socket, after the connection object value has been removed from the container, for example? Is this shared_ptr approach the idiomatic or even the only way to manage lifetimes in ASIO async calls? It just looks a bit ugly to me, bloats the code a bit and I was wondering if there is any other way to do it without the intrusion of shared_ptrs into the mix? Tom

2 1

Interest in updated, standalone iterator_facade library?
by Zach Laine 11 Aug '19

11 Aug '19

I write a lot of iterators, and I'm getting sick of doing it by hand. I can't use Boost.Iterator's iterator_facade in library code, since it knows nothing about constexpr and noexcept. The design of Boost.Iterator's iterator_facade does not lend itself very well to being modified in a direction that is standardization-friendly (reasons why are outlined in the online docs). So, here is one take on this problem: GitHub: https://github.com/tzlaine/iterator_facade Online Docs: https://tzlaine.github.io/iterator_facade For those unfamiliar with the problem, iterators are very simple, at the highest level of abstraction. An iterator's implementation does not reflect this -- it is highly repetitive and easy to get subtly wrong. This library fixes that. The library is forward-looking, since I intend to write WG21 papers to standardize iterator_facade; there is good support for upcoming C++20 library features. In particular, the iterators created with iterator_facade model the C++20 iterator concepts, and therefore do not necessarily match the requirements of the C++17-and-earlier requirement tables. I have not found this to affect the usability of iterator-facade-based iterators with pre-C++20 code. Something to note: there was a recent-ish attempt to stanrdize iterator_facade, which is now abandoned, P0186 (http://wg21.link/P0186) This was very different from what I'm proposing for Boost. I talked to Eric Niebler about this, and he favors a return to the CRTP-based approach of my lib and the original Boost.Iterator iterator_facade library. Zach

2 1

[rational] make rational constructors noexcept
by Frédéric 06 Aug '19

06 Aug '19

Hi, I think that some rational constructors can be marked noexcept. In particular: - default constructor: rational() - constructor from integer: rational(const T& n, typename enable_if_c<...>::type const* = 0) Concerning the constructor with numerator and denominator, if the denominator is always not null, it could be noexcept but I guess we cannot enforce not null unless we use some kind of gsl::not_null. Your thoughts? Thanks, F

3 3

Question regarding Boost Logging to Windows Event Logs
by Art Strutzenberg 05 Aug '19

05 Aug '19

I'm encountering an issue with the boost logging system, backend is using windows event log backend, and I'm honestly not sure what might be going on? The symptoms: * My code is building, events ARE getting logged and showing up in the event viewer * There is no additional data getting associated to the event (in this case a "processID", "threadID", and actual message text. * The events that do show up have the following text: "ProcessId: %1 ThreadId: %2 Message: %3, * Additionally I'm noticing that the severity of the message is showing up as "Error" Here is the code snippets that I <think> might be relevant: https://pastebin.com/ttzK4r0m The mc file I'm using is: https://pastebin.com/fNyL5Zua Thanks! --Art

1 0

Boost.Build broken links in Getting started page
by David Demelier 01 Aug '19

01 Aug '19

Hello there, I was reading the page Getting started, but all references to Boost.Build point to 404. https://www.boost.org/doc/libs/1_70_0/more/getting_started/unix-variants.ht… Regards, -- David

1 0

Fatal Error LNK1104: cannot open file
by Cg K 30 Jul '19

30 Jul '19

I posted this issue originally on the boost list, largely to inform that I have been able to compile boost_1_71_0_b1_rc1 using VS 2019. See that post here: <https://lists.boost.org/Archives/boost/2019/07/246678.php> I moved this post here because I think my subsequent problem has to do with setting up Visual Studio 2019. I have followed the Getting Started in Windows <https://www.boost.org/doc/libs/1_70_0/more/getting_started/windows.html> tutorial and was able to build the simple program, aka the header only project, in VS. It compiled and ran fine. I then built the project that links your program to the Boost Library described in the tutorial. I received the following message when I compiled as x64. 1>LINK : fatal error LNK1104: cannot open file 'libboost_regex-vc142-mt-gd-x64-1_71.lib' As you can see in my original email post referred to above, I built another simple program based upon a youtube video and on VS2017 and while it compiled in the youtube video, I received a the same linker error, LNK1104 message as well. Since the file referred toin the LNK1104 error has the prefix lib, it appears that VS is looking for a static library. I built boost as shared from the Develop command line using the command. .\bj2 link=shared . This method apparently worked in VS2017 but I can not replicate it in VS2019. What am I missing?

2 2

Result of out_ptr review.
by Zach Laine 29 Jul '19

29 Jul '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

Need some help with Boost.Build
by Maarten Verhage 29 Jul '19

29 Jul '19

Dear Boost.Build expert, I do have Boost 1.69 and was able to build from the sources with Mingw-w64 gcc 8.1 on Windows 7. That was for boost itself, but now I need to build the tests for the Boost library Spirit (the parser). I cannot get this to work. My Boost.Build version is 2018.02-git. According to Boost.Build paragraph 3.3 Configuration, the option "b2 --debug-configuration" gives info how my boost.build is configured. In the folder <boost-build>\example\hello the output of "b2 --debug-configuration" looks fine. But when I run from the folder <boost-spirit-develop>\test "b2 --debug-configuration" the output contains: error: Could not find parent for project at '.'. So in the folder <boost-spirit-develop>\test I rename Jamfile to Jamroot.jam. Now with "b2 --debug-configuration" I get: output.txt (attachtment of this email) Also when I try to build the tests it I gets the same error messages strarting from: config.jam: No such file or directory How do I solve this? Best regards, Maarten Verhage

1 0

boost::test observing failures
by John Foster 27 Jul '19

27 Jul '19

I am using boost test within a home-grown GUI, and want to access test results (e.g. the failure message and location when a test fails) The unit_test::test_observer class provides the virtual method: void assertion_result(boost::unit_test::assertion_result) However, unit_test::assertion_result is just an enum indicating success or failure. From there, I cannot see how to access further information about the test result. The framework also provides the class test_tools::assertion_result, which encapsulates an error message, but this only appears to be used for evaluating pre-conditions. (I would have expected this type to be the argument to unit_test::test_observer::assertion_result). The log output classes appear to provide more information on test results. These are implemented as streams, which makes it non-trivial to extract test result data. Does anyone know how I can access the information on test results - success/failure, the test code, the location, etc? Thanks John John Foster [cid:image001.png@01D3CC10.659716E0]<http://en.wikipedia.org/wiki/Qantassaurus> Associate Director, Quant Analysis Regulatory Modelling Credit Risk Analytics and Portfolio National Australia Bank Level 15, 500 Bourke St, Melbourne VIC 3000 Tel: +61 (0)3 8641 5228 Email: john.x.foster(a)nab.com.au<mailto:John.X.Foster@nab.com.au> ________________________________ The information contained in this email communication may be confidential. If you have received this email in error, please notify the sender by return email, delete this email and destroy any copy. Any advice contained in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this email, National Australia Bank Limited (NAB) recommends that you consider whether it is appropriate for your circumstances. If this email contains reference to any financial products, NAB recommends you consider the Product Disclosure Statement (PDS) or other disclosure document available from NAB, before making any decisions regarding any products. If this email contains any promotional content that you do not wish to receive, please reply to the original sender and write "Don't email promotional material" in the subject.

2 1

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

22 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

4 4