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

[Dll] Inconsistent annotations reported under visual studio 2019
by Sean Farrow 20 Aug '19

20 Aug '19

Hi all, Whilst compiling a plugin in release mode with boost.dll 1.70 using Visual Studio 2019 and the latest Windows sdk, I'm getting several inconsistent annotation errors for functions like LoadLibraryA/W. Before I go to the trouble of creating a reproducible project and filing an issue, I wondered whether this is something that is know about and possibly fixed in 1.71 Any help appreciated. Kind regards Sean.

2 1

Re: [Boost-users] [release] Boost 1.71.0 Release Candidate 2 available
by Michael Caisse 16 Aug '19

16 Aug '19

On 8/16/19 10:22, William Jagels wrote: > > > On Wed, Aug 14, 2019, 13:29 Michael Caisse via Boost-users > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> wrote: > > The release candidates for the 1.71.0 release are now available at: > <https://dl.bintray.com/boostorg/release/1.71.0/source/> > > The SHA256 checksums are as follows: > > 1b3949ffddf56129141032542523920034f2e69775fb9332a52ba37c548dbf35 > boost_1_71_0_rc2.7z > > d73a8da01e8bf8c7eda40b4c84915071a8c8a0df4a6734537ddde4a8580524ee > boost_1_71_0_rc2.tar.bz2 > > 96b34f7468f26a141f6020efb813f1a2f3dfb9797ecf76a7d7cbd843cc95f5bd > boost_1_71_0_rc2.tar.gz > > 85a94ac71c28e59cf97a96714e4c58a18550c227ac8b0388c260d6c717e47a69 > boost_1_71_0_rc2.zip > > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. > > > -- The Boost Release Managers > > > > Built successfully with gcc 8.3.0. Was able to rebuild a large codebase > without any issues. > Thank you for giving it a spin and reporting back! -- Michael Caisse Ciere Consulting ciere.com

1 0

[release] Boost 1.71.0 Release Candidate 2 available
by Michael Caisse 15 Aug '19

15 Aug '19

The release candidates for the 1.71.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.71.0/source/> The SHA256 checksums are as follows: 1b3949ffddf56129141032542523920034f2e69775fb9332a52ba37c548dbf35 boost_1_71_0_rc2.7z d73a8da01e8bf8c7eda40b4c84915071a8c8a0df4a6734537ddde4a8580524ee boost_1_71_0_rc2.tar.bz2 96b34f7468f26a141f6020efb813f1a2f3dfb9797ecf76a7d7cbd843cc95f5bd boost_1_71_0_rc2.tar.gz 85a94ac71c28e59cf97a96714e4c58a18550c227ac8b0388c260d6c717e47a69 boost_1_71_0_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

2 1

Parallel Boost logging with multiple link units
by Simon Michalke 14 Aug '19

14 Aug '19

Hello all, I want to use boost logging with multiple link units. However all of the examples use only one source file (and only have some logging in the main function). In addition to that I need to have multithreading support as well. Do I have to initialize the sink for every module or only once for my program? Regards, Simon Michalke

1 0

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 06 Aug '19

06 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