November 2016 - Boost - lists.preview.boost.org

[compute] Remove boost::chrono lib dependencie
by Viktor Sehr 01 Dec '16

01 Dec '16

Hi, Would it be possible to remove the dependency for boost/chrono is boost/compute/detail/duration.hpp. As it already supports std::chrono via a macro, couldn't the inclusion of boost/chrono.hpp be excluded? As it is now, boost compute is dependent on having libboost_chrono-vc140-mt-gd-1_62.lib built. /Viktor

4 4

[release] Boost 1.63.0 Beta 1
by Marshall Clow 29 Nov '16

29 Nov '16

The first beta packages for 1.63.0 beta 1 are now available: <https://sourceforge.net/projects/boost/files/boost/1.63.0.beta.1/> The SHA256 checksums are as follows: 3dbc1bca10941710755c13a00b1ae56d2d37fe90bbadcf9746203194f9d33e3a boost_1_63_0.7z c8b986fd57e436fd88dbc70e51d3e21efa2be3bdf835fa499b2cf6c0a8cc2985 boost_1_63_0.tar.bz2 745d99e4be9c0f324ec7ba15b7d228fd780067f2e8aeae2f16660a4cf6e6a051 boost_1_63_0.tar.gz e66bd6e2f637148c314398b92bc1f3cbdc777ee282f9de7885697afad3d9c202 boost_1_63_0.zip As always, the release managers would appreciate it if you download the archive of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

12 21

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 29 Nov '16

29 Nov '16

Hi Vicente, >> In theory, the standard version would suffice, except for Thread. >> Boost.Thread provides interruption points, which the standard does not. >> With the standard version, I would not be able to offer task interruption. >Could you explain why task interruption is associated to thread >interruption? Ah already implementation details :) Tasks are executed in schedulers (uisually threadpools), which manage 1 to n threads. To interrupt a task from outside, the library interrupts the thread running the task. To be exact, the task will be interrupted the next interruption point in encounters. The thread executing the task does not terminate but instead recovers and pops the next task from its job queue. >> I rely for the other parts also on Boost because the standard version had >> bugs on earlier versions of compilers, and quite some projects are still >> stuck with gcc-4.9 or mingw. At some points, it seemed easier to maintain >> using Boost (which also happens to be faster than the standard, at least on >> my tests). >> >Whow, glad to hear Boost.Thread is working for you Henry. It is. I got no problem whatsoever. >I believe that Michael is however right. Boost libraries restricted to >C++11 should use the standard library as much as possible. Sure. At the moment I have no way around Boost.Thread though. If that changes, I'll probably want to switch to standard. The performance issue for the clock is not a huge one and by that time, the older compilers will hopefully have vanished. I could provide a macro to switch between boost / std. If one needn't interrupt tasks, the library would make no use of boost at all. >It would be great to have a specific C++11 (language and standard >library) version of your library. Well, if there is interest, why not? >Good luck with the review, >Vicente >P.S. I've in my todo's list implement thread interruption on top of the >standard as Anthony showed in his book, but I have no time to work on >this now. Oh, it would be great. This really is a fantastic feature. Thanks, Christophe

1 0

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 29 Nov '16

29 Nov '16

Hi Michael, >Thank you for submitting this library to the the incubator in >preparation for a review. I saw your presentation in 2014 >and I believe that this library solves a common problem. >My first question: I see that the library is listed as C++11 and also >has dependencies on Boost.System, Boost.Thread, Boost.Chrono, >and Boost.DateTime. Much of the functionality provided by those >Boost libraries is now part of the C++11 or C++14 standard. >Can you comment on the specific Boost dependencies >and if the standard versions would suffice? A good question which deserves a rationale, which I will add. In theory, the standard version would suffice, except for Thread. Boost.Thread provides interruption points, which the standard does not. With the standard version, I would not be able to offer task interruption. I rely for the other parts also on Boost because the standard version had bugs on earlier versions of compilers, and quite some projects are still stuck with gcc-4.9 or mingw. At some points, it seemed easier to maintain using Boost (which also happens to be faster than the standard, at least on my tests). HTH, Christophe

2 1

[ssl] SSL handshake takes forever sometimes
by Shuchen He 28 Nov '16

28 Nov '16

Hi, I have an application written in boost with SSL. I noticed that when the client network is down for a while and come back again. The SSL handshake sometimes take forever. I tried to kill the client application and run it again, the problem still there. The only way to make it work again was to reboot my client device. I'm using boost 1.60 on the client side and 1.58 on the server side. The SSL handshake code was copied from Boost SSL server and client example I modified a bit to suit my application needs. Does anyone experience the similar issue? If so, can you please let me know how do you fix it? It would be much appropriated if you could help me out on this issue. Below is the SSL handshake code. chat_client(boost::asio::io_service& io_service, boost::asio::ssl::context& context, tcp::resolver::iterator endpoint_iterator) : io_service_(io_service), socket_(io_service, context) { filesize_=0; isfileopen_=false; socket_.set_verify_mode(boost::asio::ssl::verify_peer); socket_.set_verify_callback( boost::bind(&chat_client::verify_certificate, this, _1, _2)); boost::asio::async_connect(socket_.lowest_layer(), endpoint_iterator, boost::bind(&chat_client::handle_connect, this, boost::asio::placeholders::error)); } bool verify_certificate(bool preverified, boost::asio::ssl::verify_context& ctx) { char subject_name[256]; X509* cert = X509_STORE_CTX_get_current_cert(ctx.native_handle()); X509_NAME_oneline(X509_get_subject_name(cert), subject_name, 256); log_time(); fprintf(logfile,"%s: Verifying %s\n",logtime.c_str(), subject_name); return preverified; } void handle_connect(const boost::system::error_code& error) { if (!error) { socket_.async_handshake(boost::asio::ssl::stream_base::client, boost::bind(&chat_client::handle_handshake, this, boost::asio::placeholders::error)); } else { log_time(); fprintf(logfile, " %s Connect to server failed: %s\n ",logtime.c_str(), error.message().c_str()); fflush(logfile); delete this; } } void handle_handshake(const boost::system::error_code& error) { if (!error) { ssl_handshake_ok=1; do_read_header(); } else { log_time(); fprintf(logfile,"%s: Handshake failed:%s\n ",logtime.c_str(), error.message().c_str()); } }

1 0

[poly_collection] request for help at performance testing
by Joaquin M López Muñoz 28 Nov '16

28 Nov '16

Hi, Some days ago I published the first version of (candidate) Boost.PolyCollection at https://github.com/joaquintides/poly_collection Performance tests are available at http://rawgit.com/joaquintides/poly_collection/website/doc/html/poly_collec… but GCC and Clang were run in a Travis VM and the resulting figures are noisy and not sufficiently accurate. I'm looking for volunteers willing to run the performance suite in one or more of the following environments: * Recent GCC, 32 bit * Recent GCC, 64 bit * Recent Clang 32 bit * Recent Clang, 64 bit The full suite in one environment takes 1.5-2h to execute. If you're interested, please contact me privately (so that we don't pollute the mailing list) and I'll provide you with further instructions on how to do the testing. Thank you! Joaquín M López Muñoz

1 0

[iterator] Orbiting iterators
by Jeremy Murphy 27 Nov '16

27 Nov '16

Hi, just wondering what the mood in Boost.Iterator is for new features? At work we recently found use for an orbiting iterator, specifically a circular one, which effectively wraps at the start/end of a bounded range. (The domain is digital signal processing.) Implementation details aside, does this feature sound desirable to the library? I call it an "orbiting" iterator because it is a specific (and useful) case of the more general rho-shaped orbiting iterator. The theory behind it is in chapter 2 of Elements of Programming, which happens to be the free sample chapter available: http://elementsofprogramming.com/032163537X_Sample.pdf#page=6 Anyway, if there is interest, I'll make a pull request. Cheers. Jeremy

6 10

Re: [boost] [beast] Separation between parse and generation and asio
by Vinnie Falco 24 Nov '16

24 Nov '16

On Wed, Nov 23, 2016 at 10:45 PM, Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> wrote: > I'm trying Beast with avr-gcc to see how much footprint it would take > on embedded applications. Thank you for your interest in Beast! > Unfortunately, stream_concepts uses asio > types, which requires asio include which requires network includes > which will obviously fail in most microcontrollers. > > Would it be possible to make parse and read implementation less > dependent on each other? I see what you mean. Yes, I believe I can do that - would you mind creating a new issue here? https://github.com/vinniefalco/Beast/issues Thanks!

1 0

[outcome] Requesting pre-review of Boost.Outcome tutorial
by Niall Douglas 24 Nov '16

24 Nov '16

Dear Boost, I am hoping to bring Boost.Outcome, a C++ 14 library providing a factory and family of policy driven lightweight monadic value-or-error transports, into the Boost peer review queue by March 2017 followed shortly thereafter by an ACCU talk in April if my talk proposal passes their programme committee. To that end, I've written an explanation and a sort of tutorial explaining the history and purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd greatly appreciate if people could tell me: 1. Does it make sense? 2. Do you think you could use Outcome in your own code after reading it? 3. Do you think you would want to use Outcome in your own code after reading it? 4. Are there any missing parts which are showstoppers? My thanks in advance. Be aware the install stuff described at the start doesn't work yet. The reference documentation is also quite patchy thanks to doxygen not understanding CRTP. All that stuff and a fair bit more remains to fix before it's ready to enter the Boost peer review queue. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 14

[beast] Separation between parse and generation and asio
by Felipe Magno de Almeida 24 Nov '16

24 Nov '16

Hello, I'm trying Beast with avr-gcc to see how much footprint it would take on embedded applications. Unfortunately, stream_concepts uses asio types, which requires asio include which requires network includes which will obviously fail in most microcontrollers. Would it be possible to make parse and read implementation less dependent on each other? Boost.Spirit x3 works very well on microcontrollers. I'd expect a different type for messages which could actually receive iterator pairs for strings with Beast might give a very good option for HTTP/WS implementation on microcontrollers. Regards, -- Felipe Magno de Almeida

1 0