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

Turning off BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS for MSVC++
by Billy O'Neal (VC LIBS) 17 Apr '18

17 Apr '18

Hi folks! As part of a recent cleanup of some of our iostreams bits I removed a double-seek inside std::filebuf. (Previously, std::filebuf didn't take advantage that we know ::fsetpos just accepts a 64 bit number position) Moreover, in previous releases of MSVC++, that still would have been correct; filebuf was getting to the same place in a very indirect way. I know just casting std::fpos to a streamoff works to get the position going back to at least VS 2015, and it probably works a decade earlier than that (though I have not tested). Shame on us for adding a pretty name to std::fpos not depicted in the standard. Would you accept a patch to $\boost\iostreams\detail\config\fpos.hpp adding this guard before attempting to define BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS? !(_MSVC_STL_VERSION >= 141) I submitted a patch to do that here: https://github.com/boostorg/iostreams/pull/57 Thanks folks! Billy O'Neal Visual C++ Libraries

3 2

Boost.Range and result_type
by Robert Jones 17 Apr '18

17 Apr '18

Hi All I have a suspicion this is all ancient history now, but I was surprised this code worked. #include <iostream> #include <vector> #include <boost/range/adaptor/transformed.hpp> struct TimesTwo { // using result_type = int; int operator( )( int i ) const { return i * 2; } }; int main( ) { using namespace std; using namespace boost::adaptors; vector<int> v { 0, 1, 2, 3, 4, 5 }; for( int i : v | transformed( TimesTwo( ) ) ) { cout << i << " "; } cout << endl; } Due to result_type being commented out. Am I right in thinking this is what BOOST_RESULT_OF_USE_DECLTYPE was all about, and everything now just works because modern compilers are implemtenting decltype now? Kind Regards Rob.

2 1

[DateTime] localtime_r() issue
by Latimerius 16 Apr '18

16 Apr '18

Hi, I'm trying to build a project that uses Boost.Log (which in turn uses Date_Time) from Boost 1.65.1 on a platform that uses Clang with (apparently) Dinkumware for a standard library implementation. Compilation fails in date_time/c_time.hpp on line 67 due to a use of undeclared identifier 'localtime_r'. The standard library implementation indeed doesn't seem to have localtime_r(), just localtime_s(). Compilation of the failing code in c_time.hpp is enabled by the preprocessor symbol BOOST_DATE_TIME_HAS_REENTRANT_STD_FUNCTIONS having been #define'd which happens in date_time/compiler_config.hpp based on BOOST_HAS_THREADS being #define'd and a bunch of compiler checks that probably don't get it quite right. Could someone give me some advice how to deal with this? Thanks in advance!

1 0

[release] Boost 1.67.0
by Daniel James 15 Apr '18

15 Apr '18

Release 1.67.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 2 new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <https://www.boost.org/users/news/version_1.67.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.67.0/> To install this release on your system, see <https://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team

3 3

Convert boost::shared_ptr to std::shared_ptr for boost::dll::import
by David Demelier 13 Apr '18

13 Apr '18

Hello, In my application I use std::shared_ptr in the public API for loading plugins. I wanted to use boost::dll to import dynamically plugins as well. It looks like for some reasons that it still use boost::shared_ptr instead of std::shared_ptr even though C++11 is 7 years old. I wanted to convert the boost shared_ptr to std with the following function: std::shared_ptr<plugin> load(boost::shared_ptr<plugin> ptr) { return std::shared_ptr<plugin>(ptr.get(), [ptr] (auto) {}); } It works at perfectly at runtime, however my application segfaults at end, when destroying objects. I suspect that it's because the internal boost::dll shared_library is destroyed **before** my own shared_ptr. The backtrace: (gdb) bt #0 0x00007ffff3f054d8 in ?? () #1 0x00007fffffffdb80 in ?? () #2 0x00007ffff4109400 in ?? () #3 0x00007ffff4add6f8 in _nl_current_default_domain () from /lib64/libc.so.6 #4 0x00007ffff47641d8 in __run_exit_handlers () from /lib64/libc.so.6 #5 0x00007ffff476422a in exit () from /lib64/libc.so.6 #6 0x00007ffff474df31 in __libc_start_main () from /lib64/libc.so.6 #7 0x0000000000413c1a in _start () Is there any chance I can safely convert the smart pointer? Regards, -- David

8 12

Credits to Boost.Asio
by David Demelier 13 Apr '18

13 Apr '18

Hello, I'm the author of irccd [0], a C++ IRC bot extensible with plugins. Up to the 3.0.0 version current in development, I had my network code written by myself (being used of lots of poll(2) usage in C). I have switched to Boost.Asio a while ago to remove my own code and facilitate further development. Even though I think it has its learning curve, I enjoyed a lot the switch and tested my IRC bot to connect 100 times in the same instance to my own local IRC server. It took less than 2 seconds to join all requested channels, taking only 2MB of RAM. This is just awesome. Congratulations for this powerful module :) [0]: http://projects.malikania.fr/irccd -- David

1 0

boost::rational does not maintain its invariant in case of overflow
by Frédéric 11 Apr '18

11 Apr '18

With the program shown below, I obtained the following output: std::numeric_limits<long>::max() == 9223372036854775807 r == boost::rational<long>(4294967296, 1853020188851841) == 4294967296/1853020188851841 r * r == 0/8733086111712066817 Clearly there are 2 overflows but this leads to the invariant of the class not being maintained, i.e. the faction is not simplified to 0/1 (gcd(num, den) != 1). F #include <boost/rational.hpp> #include <iostream> int main() { std::cout << "std::numeric_limits<long>::max() == " << std::numeric_limits<long>::max() << '\n'; boost::rational<long> r(4294967296, 1853020188851841); std::cout << "r == boost::rational<long>(4294967296, 1853020188851841) == " << r << '\n'; std::cout << "r * r == " << (r * r) << '\n'; return 0; }

2 2

How do I "run the configure tests"?
by Chris Stankevitz 10 Apr '18

10 Apr '18

Can't find anything about it in the docs. "Unknown compiler version - please run the configure tests and report the results" [1] Thank you, Chris [1] From https://www.boost.org/doc/libs/1_65_1/boost/config/compiler/visualc.hpp

4 5

Toolset version for Visual Studio 2017 15.6.3
by Chris Stankevitz 10 Apr '18

10 Apr '18

What version should I pass to b2 --toolset=msvc-x.y for "Visual Studio 2017 15.6.3"? [1] says [2] will have an up-to-date list with an answer, but [2] is not up-to-date. Thank you, Chris [1] https://www.boost.org/doc/libs/1_65_1/more/getting_started/windows.html#ide… [2] https://www.boost.org/build/doc/html/bbv2/reference/tools.html

4 4

[asio] SSL async_shutdown() never finishes if called when async_read_some() is in progress
by Alexander D. 08 Apr '18

08 Apr '18

Hello, I'm writing a middleware which basically adds an SSL layer to the connection between a client and a server. The connection is bidirectional, so I need to read from each side and write to the other. The client can also close the connection at any time, in which case async_shutdown() must be called on the server's stream. The problem is, often the shutdown happens when the program is waiting on the server through async_read_some(), and the shutdown will never finish. The following code illustrates this issue: #include <iostream> #include <boost/asio.hpp> #include <boost/asio/ssl.hpp> int main(int argc, char* argv[]) { try { boost::asio::io_context io_context; boost::asio::streambuf buffer; boost::asio::ssl::context ctx(boost::asio::ssl::context::tlsv12); ctx.set_verify_mode(boost::asio::ssl::verify_none); boost::asio::ssl::stream<boost::asio::ip::tcp::socket> sock(io_context, ctx); sock.next_layer().connect(boost::asio::ip::tcp::endpoint( boost::asio::ip::make_address("127.0.0.1"), 4433)); sock.handshake(boost::asio::ssl::stream_base::client); /* "async_shutdown" won't appear unless async_read_some() * is commented out */ sock.async_read_some(buffer.prepare(1024), [](boost::system::error_code, size_t) {std::cout << "async_read_some" << std::endl;}); sock.async_shutdown([](boost::system::error_code) {std::cout << "async_shutdown" << std::endl;}); io_context.run(); } catch (std::exception& e) { std::cerr << "Exception: " << e.what() << "\n"; } return 0; } To reproduce, start up an SSL server: openssl genrsa -out key.pem 2048 openssl req -new -sha256 -key key.pem -out csr.csr openssl req -x509 -sha256 -days 365 -key key.pem -in csr.csr -out server.pem openssl s_server -key key.pem -cert server.pem and run the program. Notice that "async_shutdown" does not finish even if the server is killed. In practice, this leaks the memory of the shutdown handler and whatever is bound to it. The only solution I can think of would be to cancel the read operation, but there's no portable way in asio to do this. Can someone point out how to solve this? Cheers, Alexander

5 11