December 2018 - Boost - lists.preview.boost.org

Feature/cmake-config merged to develop; yml files need to be updated
by Peter Dimov 19 Dec '18

19 Dec '18

I've just merged the superproject branch feature/cmake-config to develop. This updates `b2 install` to export CMake configuration files into the `cmake` subdirectory of the library directory. These configuration files enable a Boost installation to be used from CMake via `find_package(boost_filesystem)`, without relying on FindBoost. Unfortunately, this change adds two necessary submodules to the superproject, `tools/boost_install` and `libs/headers`. As a result, all .travis.yml and appveyor.yml files that rely on a partial checkout need to be updated to perform git submodule update --init tools/boost_install git submodule update --init libs/headers in addition to the usual git submodule update --init tools/build git submodule update --init libs/config I'm sorry for the inconvenience this will cause, or perhaps already has caused.

5 7

Ignoring unused type aliases in concepts
by Mateusz Loskot 18 Dec '18

18 Dec '18

Hi, In concepts, such unused type aliases are not uncommon. What is the best way to ignore compiler warnings about those? Options I'm aware of are: 1. Adjust compile options in build configuration (Jamfile) 2. Use #pragma in headers 3. Use boost::ignore_unused_variable_warning(alias{}) (or little brother boost::ignore_unused) 4. Ignore ignoring them. The options 1 and 2 are mentioned on https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines The option 3 is not and is there any particular reason why? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 16

Error to convert to boost::asio::streambuf to raw buffer char *buffer
by hh h 18 Dec '18

18 Dec '18

boost::asio::streambuf sb; char *raw = sb; error: cannot convert ‘boost::asio::streambuf {aka boost::asio::basic_streambuf<>}’ to ‘char*’ in initialization I've checked the boost::asio::streambuf reference, but could not find anything to fix it, appreciate any clues.

3 3

[cmake] Has the latest effort stalled?
by Andrey Semashev 17 Dec '18

17 Dec '18

Hi everyone, hi Robert, I've been informed[1] that the latest effort to call for CMake submissions and then review them collectively in February has stalled or failed. Is this true? What is the status of this effort, and if it's still on track, what is the current schedule? I'm asking because there is an ongoing effort by Mike-Devel (sorry, don't know your full name) to add minimalistic support for CMake across a number of Boost libraries, including those I maintain, and I've been holding off his submissions until after the review according to Robert's plan. If that plan is no longer in force, I might as well accept Mike's PRs and we (Boost as a whole) might as well accept his solution as the only one we have close to implementation. [1] https://github.com/boostorg/winapi/pull/73#issuecomment-447760554

2 1

Mixing async/sync code thanks to boost::context
by Christophe Bailly 16 Dec '18

16 Dec '18

Hello, I am new in this mailing list, I hope this is the right list to post my issue. Context: I often have to deal with some code which is originally synchronous. When we introduce an asynchronous call, all the callers must be made asynchronous with async/await everywhere. Let's take a concrete example: Suppose we have an existing synchronous library which makes computation. Suppose we can give a custom function to this library to compute a part of the calculation. We decide that this function will call a server... We may wish the main compute function to become asynchronous... Now the big question: Why isn't it possible so far to do this without changing all the functions ?? I find this really ugly, this is really difficult to make a good design. With asymetric async calls, I doubt this is possible, so I tried boost::context. In my example, the "library" is represented by the function calculate which is synchronous. It calls a function call_server which simulates the call to a server, in fact it will just wait for 5 seconds but in a asynchronous way. The main function will do a computation in parallel while the server will be called. You will find the code at the end of the mail. This sounds too good to be true but in this case, where did I miss something ? I haven't implemented a socket with a select but this would work, right ? The library can still be used in an asynchronous or synchronous context (with no extra cost). To help the understanding of the code, we have 3 tasks, the continuation are stored in the tasks vector. task are identified thanks to their indice in the vector: - 0: main task (id_main) - 1: reactor(id_reactor) - 2; computation_task (id_computation) I implement a kind of future, whose value is retrieved at the end of the main function and which launches a task to compute the value. Remarks: 1/ This is not optimised, we could make fewer context switches. There is no need for a specific task for the reactor, it could be called directly. 2/ The call_server function could detect automatically the sync or async context, if the reactor is not active (no waiting tasks to be run), then it would run i a synchronous way. 3/ This solution is based on a singleton for the reactor, but this is what we want, 4/ This could be certainly better coded, I am not an expert, I use to code more in Python and wanted to use C++ to see if I could solve these designs problems. I am curious to read what you think about this, I certainly missed something so please clarify and tell me if a clean solution is possible. Thanks a lot for reading. Regards, Chris #include <boost/lambda/lambda.hpp> #include <iostream> #include <iterator> #include <boost/context/continuation.hpp> #include <iostream> #include <string> #include <vector> #include <tuple> #include <queue> #include <time.h> int a = 0; int result = 0; namespace ctx = boost::context; std::vector<ctx::continuation> tasks; std::queue<int> tasks_to_run; std::vector<int> end_tasks; // list of tasks which ended using clock_info = std::tuple<int, time_t, int>; // task, start_time, duration using wait_info = std::tuple<int, int>; // source, target: source wainting for target to end std::queue<clock_info> clocks; // timer to wake up tasks std::queue<wait_info> waits; const int id_main = 0; const int id_reactor = 1; const int id_computation = 2; void add_clock(int task, int duration) { time_t start; time(&start); clocks.push(std::make_tuple(task, start, duration)); } void wait_for(int source, int target) { waits.push(std::make_tuple(source, target)); } void end(int task) { end_tasks.push_back(task); } ctx::continuation reactor(ctx::continuation && main_continuation) { ctx::continuation task; std::cout << "start reactor" << std::endl; tasks.push_back(std::move(main_continuation)); // add main continuation to list of tasks tasks_to_run.push(id_main); unsigned int k; time_t end_time; for (;;) { if (tasks_to_run.size()) { int id_task = tasks_to_run.front(); tasks_to_run.pop(); tasks[id_task] = tasks[id_task].resume(); } time(&end_time); for (k = 0; k < clocks.size(); k++) { clock_info clock = clocks.front(); int elapsed = end_time - std::get<1>(clock); if (elapsed > std::get<2>(clock)) { tasks_to_run.push(std::get<0>(clock)); } else clocks.push(clock); clocks.pop(); } for (k = 0; k < waits.size(); k++) { wait_info wait = waits.front(); if (std::find(end_tasks.begin(), end_tasks.end(), std::get<1>(wait)) != end_tasks.end()) { tasks_to_run.push(std::get<0>(wait)); } else waits.push(wait); waits.pop(); } } return std::move(main_continuation); } struct int_future { std::function<int()> func; int future_result; int_future(std::function<int()> f) :func(f) {} auto make_task() { return [this](ctx::continuation && main_cont) { tasks[id_reactor] = main_cont.resume(); future_result = this->func(); end(id_computation); tasks[id_reactor] = tasks[id_reactor].resume(); return std::move(main_cont); }; } int get() { wait_for(id_main, id_computation); tasks[id_reactor] = tasks[id_reactor].resume(); return future_result; } }; int call_server() { std::cout << "waiting for server results" << std::endl; add_clock(id_computation, 5); tasks[id_reactor] = tasks[id_reactor].resume(); result = 5; std::cout << "server returned result " << result << std::endl; return result; } int calculate() { return 1 + call_server(); } int main() { ctx::continuation task; tasks.push_back(ctx::callcc(reactor)); std::cout << "launch computation task" << std::endl; int_future fut(calculate); tasks.push_back(ctx::callcc(fut.make_task())); tasks_to_run.push(id_computation); tasks_to_run.push(id_main); tasks[id_reactor] = tasks[id_reactor].resume(); std::cout << "main task running" << std::endl; for (int j = 0; j < 10; ++j) { std::cout << a << " "; } std::cout << std::endl; std::cout << "wait for future" << std::endl; std::cout << "future result:" << fut.get() << std::endl; }

4 6

[docs] Building docs for release?
by John Maddock 15 Dec '18

15 Dec '18

Is there now a way for quickbook docs that aren't integrated under /doc/ to be built automatically for each release? And if so, what's the magic incantation to test this? Many thanks! John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

Windows quarantines boost_1_68_0.7z
by Miguel Ojeda 15 Dec '18

15 Dec '18

Quick note: it seems that Windows currently quarantines boost_1_68_0.7z. Could someone from Boost please contact Microsoft to whitelist it? Thanks, Miguel

5 11

C++Now (BoostCon) 2019 Call for Submissions
by Jon Kalb 14 Dec '18

14 Dec '18

The C++Now (formerly BoostCon) 2019 Call for Submissions is now open. http://cppnow.org/announcements/2018/12/2019-call-for-submissions/ C++Now will be held in Aspen, Colorado on May 5th - 10th. Colorado has become trendy for C++ conferences, but BoostCon was here first. If you are interested in Boost Libraries and have never attended C++Now, you owe it to yourself to have the BoostCon experience. The best way to get your company to send you is to have an accepted submission. The deadline is early in the new year, so don’t delay. Jon Kalb Conference Chair C++Now

1 0

Let's discuss dropping support for msvc <= 9.0 (2008), gcc < 4.6, clang < 3.4
by James E. King III 13 Dec '18

13 Dec '18

During the Boost 1.69.0 release there was a regression on Visual Studio 2005 (msvc-8.0). Microsoft ended support for msvc-8.0 on December 4, 2016. I was going to argue we let it happen, but it wasn't the right time to discuss that sort of change. Boost has a very large compatibility matrix which increases the effort required, and sometimes limits solutions development, to get out a quality release. The boost project as a whole agreed in summer 2018 that if repository maintainers wanted to drop C++03 support per repository to make substantial improvements or simplifications, or to ease maintenance then they are able to do so. *Folks who need support for older language levels and older compilers can always download an older version of Boost.* The compilers I mentioned in the subject have trouble with C++11 and are no longer maintained. msvc-8.0 (Visual Studio 2005) ended support Dec 10 2016 msvc-9.0 (Visual Studio 2018) ended support April 10 2018 The last release of gcc 4.6 was April 12, 2013 The last release of gcc 4.5 was July 02, 2012 The last release of gcc 4.4 was March 13, 2012 The compilers by default in Ubuntu Trusty 14.04.5 LTS, supported through April 2019, is gcc-4.8, currently at gcc-4.8.2, and clang 3.4 (however clang-3.8 is available). My argument is that this is a huge project, and maintaining backwards compatibility is not always efficiently possible. We spend build matrix resources testing and analyzing those tests. We find and develop fixes and workarounds. In some cases we hobble potential solutions to cater to decade-old compilers. Given the summer 2018 discussions about language level, and the aging vendor support matrix, I'd like us to consider dropping support for msvc <= 9.0 (2008), gcc < 4.6, clang < 3.4. What does this mean exactly? 1. We no longer test these compilers in the post-commit build matrix. 2. We no longer test these compilers in continuous integration. 3. We no longer develop fixes for issues that affect these compilers. 4. We are allowed, over time, to remove workarounds for these compilers. 5. We no longer block releases due to incompatibility with these compilers. 6. We remove these compilers from the documented environments in the release notes. 7. We direct anyone looking for support of these compilers to download a previous release of Boost that given them that support. 8. We do not update older Boost releases to fix issues with older compiler support. What would we remove from the release notes as a result? primary: linux: clang: c++03: 3.0 c++0x: 3.0 c++11: 3.0, 3.1, 3.2, 3.3 gcc: c++03: 4.4.7, 4.5.3 c++0x: 4.4.7 windows: gcc: c++03: 3.4.5, 4.1.2, 4.2.4, 4.3.3, 4.4.0, 4.5.4 msvc: - msvc-7.0 (Visual C++ 7.1) - msvc-8.0 (Visual Studio 2005) - msvc-9.0 (Visual Studio 2008) additional: linux: clang: c++03: 3.0, 3.8.1, 3.9.1, 4.0.1 c++0x: 3.0 c++11: 3.0, 3.1, 3.2, 3.3 gcc: c++03: 4.4.7, 4.5.3 c++0x: 4.4.7 windows: gcc: c++03: 3.4.5, 4.1.2, 4.2.4, 4.3.3, 4.4.0, 4.5.4 msvc: - msvc-7.0 (Visual C++ 7.1) - msvc-8.0 (Visual Studio 2005) - msvc-9.0 (Visual Studio 2008) The release notes section on compiler compatibility should probably be updated to match the current state of the post-commit matrix and duplicates in the "additional" section that are present in the "primary" section should be removed, or simply merge them. Why do we have a distinction here? Thanks for your consideration, Jim

12 16

Is disabling boost log auto flush the only way to control the log flush? Or can you change log auto flush rate?
by hh h 13 Dec '18

13 Dec '18

Hi, I use boost log in an embedded system where flushing log message to flash storage need be controlled. I could not find how to change log auto flush rate, is it the only way to disable auto flush boost::log::keywords::auto_flush = false? I think there must be a way to change a desired log flush rate value without disabling auto flush, appreciate any tips. Thank you. JHH

2 2

[coroutine] Boost.Coroutine 1.0 Deprecation Warning
by Vinnie Falco 13 Dec '18

13 Dec '18

Can we please turn off this deprecation warning for now? At least when Boost.Coroutine is being included to work with Asio? I get neverending complaints from users about this warning in Beast: <https://travis-ci.org/vinniefalco/beast/jobs/466272022#L1091> I am of course defining BOOST_COROUTINES_NO_DEPRECATION_WARNING: <https://github.com/boostorg/beast/blob/010fb4b08c05ce82cf4a87d9985c5b4998d9…> But this warning happens when building the coroutine library not when compiling Beast's tests and examples. Regards

3 2

[release] 1.70.0 open for merging
by Marshall Clow 12 Dec '18

12 Dec '18

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

2 1

GSOC-19 Ideas
by Arihant Samar 12 Dec '18

12 Dec '18

Dear Boosters, I am new to the community. I wanted to ask if there will be any new suggested GSOC ideas for 2019. I went through the suggested proposals of 2018 but projects have already been done on most of them so It will be helpful if you could give some starting points. Sent from Mail for Windows 10 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 2

[release] Boost 1.69.0
by Marshall Clow 12 Dec '18

12 Dec '18

Release 1.69.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 numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.69.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.69.0/> SHA-256 sums: af05616f71006f97833e130aad886c96136457511ace4b5496d6566e69cbe0ca boost_1_69_0.7z 8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406 boost_1_69_0.tar.bz2 9a2c2819310839ea373f42d69e733c339b4e9a19deab6bfec448281554aa4dbb boost_1_69_0.tar.gz d074bcbcc0501c4917b965fc890e303ee70d8b01ff5712bae4a6c54f2b6b4e52 boost_1_69_0.zip To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Marshall Clow, Daniel James, Micheal Caisse

2 3

[release] 1.69.0 closed for release
by Marshall Clow 12 Dec '18

12 Dec '18

The master branch is now closed for all changes except by permission. The commit-bot isn't running on master, so the super project will need to be manually updated for any changes. If all goes well, the release candidate should be out later today. Thanks, -- The Boost Release Team

4 7

The Master branch is still closed; it will be opened tomorrow
by Marshall Clow 12 Dec '18

12 Dec '18

Thanks for your patience -- The boost release managers

1 0

Fwd: [run-clang-tidy] new replacement overlaps with an existing replacement
by Mateusz Loskot 11 Dec '18

11 Dec '18

(I'm forwarding here my clang-tidy problem I posted to cfe-user mailing list, since it touches Boost library, a highly templated library, and I'm hoping we have experienced clang-tidy users among Boost developers. Considering it a part of Boost library development, I hope it is not off-topic here.) ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Mon, 10 Dec 2018 at 22:14 Subject: [run-clang-tidy] new replacement overlaps with an existing replacement To: <cfe-users(a)lists.llvm.org> Hi, I'm running clang-tidy 7.0 (also tried 5.0) to modernise some aspects of Boost.GIL (https://github.com/boostorg/gil) source code. I've noticed, clang-tidy 7.0 (also 5.0) does not apply fixes for some of modernize-use-* checks, especially modernize-use-using. I run it this way: ``` cd ${BOOST_ROOT}/libs/gil cmake -S . -B _build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON .. run-clang-tidy.py -p=_build -header-filter='boost\/gil\/.*' -checks='-*,modernize-use-using' -fix ``` Then, I see huge number of "The new replacement overlaps with an existing replacement." diagnostics. Below, I copied an extract that hopefully is useful to figure out what is happening and going wrong. Basically, there are two class templates and a bunch of tag types: 1. file_stream_device https://github.com/boostorg/gil/blob/e0288ece9ec50534e7d02166863d6799a5932e… 2. get_write_device with partial specialisations, `enable_if`-ed https://github.com/boostorg/gil/blob/e0288ece9ec50534e7d02166863d6799a5932e… The file_stream_device is specialised for a tag and final get_write_device specialisation is matched. And, clang-tidy tries to substitute this alias in get_write_device typedef detail::file_stream_device< FormatTag > type; not with using type = detail::file_stream_device< FormatTag > ; but with `using type` for each FormatTag-based specialisation ``` New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<bmp_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<bmp_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<jpeg_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<png_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<png_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<png_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<pnm_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<targa_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<targa_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<tiff_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. New replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<tiff_tag>" Existing replacement: /mnt/d/boost.wsl/libs/gil/include/boost/gil/io/get_write_device.hpp: 1885:+52:"using type = detail::file_stream_device<FormatTag>" The new replacement overlaps with an existing replacement. ``` Why clang-tidy tries to re-fix the typedef with new replacement instead of keeping the existing one, the generic one? i.e. using type = detail::file_stream_device<FormatTag> I've tried to prepare a minimal example, but I couldn't reproduce this issue. I observed, that if I manually prepare compile_database.json with single .cpp file that just `#include <boost/gil/io/device.hpp>`, that is the header with definition of the base templates and no definitions with higher level specialisations for format tags are included, then clang-tidy applies the expected fixes without any warnings. Could anyone share any insights about this issue? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

How to install boost core
by Nipun Ramani 11 Dec '18

11 Dec '18

I am very new to boost and I have been wanting to build the library from scratch. I am using CMake with VS2017. I successfully created the project files of boost-core using CMake however I am unable to locate .lib file or .dll file after I run the build in VS2017.

2 1

[Website] Revised $Date$
by Olaf van der Spek 11 Dec '18

11 Dec '18

Hi, I don't think this is what it's supposed to be. > Revised $Date$ https://www.boost.org/development/index.html -- Olaf

1 1

Reminder: 1.69 closes for major changes Wednesday
by Marshall Clow 10 Dec '18

10 Dec '18

Upcoming dates: * 31-Oct: Boost 1.69.0 closed for major code changes * 7-Nov: Boost 1.69.0 closed for beta * 14-Nov: Boost 1.69.0 beta 1 * 5-Dec: Boost 1.69.0 closed for release * 12-Dec: Boost 1.69.0 release -- The Boost Release Team

4 3

Will the boost::asio::streambuf keep in sequency order when ostream write to boost::asio::streambuf multiple time?
by hh h 10 Dec '18

10 Dec '18

Hi, Are there any problems in following statements? The receiver works a few minutes, then got wrong number in header field. std::shared_ptr<boost::asio::streambuf> buffer = std::make_shared<boost::asio::streambuf>(); std::ostream os(buffer.get()); os.write((char *) &sendHeader, sizeof(sendHeader)); os.write((char *) sb.data(), sb.size()); boost::asio::async_write(socket_, *buffer.get(), .....); Thank you. - JHH

2 1

Is the async_read more reliable than async_read_some?
by hh h 09 Dec '18

09 Dec '18

Hi, I have been using asio::async_read with protobuf for some time, it is relative easy to use protobuf function SerializeToOstream to attach a packet header and send the packet header along with to protobuf message, with fixed packet header size and message size in the header, I was able to use async_read. But I have to change to use msgpack which I could not find a way like protobuf to attach a packet header to msgpack message. The only way I could do is to use async_read_some, but I am very concerning the remark in the async_read_some document. Appreciate your comments. "The read operation may not read all of the requested number of bytes. Consider using the async_read function if you need to ensure that the requested amount of data is read before the asynchronous operation completes." Thank you. - JH

3 9

Re: [boost] Can we skip the __boost_check_library__.test ?
by Rene Rivera 07 Dec '18

07 Dec '18

Rerouting to appropriate lists.. On Sun, Dec 2, 2018 at 6:00 PM Kuhl, Brian via Boost-build < boost-build(a)lists.boost.org> wrote: > Hi Boost builders, > > We currently running the Boost test suite using ./b2 in the status > directory. > > We run nightly on several simulators and real boards using ARM, PowerPC, > Intel processors compiling Boost 1.68 with clang and GCC > > Our test results are being peppered with the occasional failure of > __boost_check_library__ > > I’m pretty sure we don’t care about the results of this test in the > context cross-compiling VxWorks? > Probably not. > What exactly is it testing for? > It checks various requirements and guidelines of the library structure. > And assuming it isn’t relevant, how do we “turn it off”? > Add the "--no-check-libs" per < https://github.com/boostorg/boost/blob/develop/status/Jamfile.v2#L18> (I believe running b2 --help in that dir would have shown you that info also). > The library Jam files don’t have an explicit reference to this that I can > find? > It's added here < https://github.com/boostorg/boost/blob/develop/status/Jamfile.v2#L119>. And it runs this script < https://github.com/boostorg/boost/blob/master/status/boost_check_library.py >. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

[release] Boost 1.69.0 Release Candidate 1
by Marshall Clow 07 Dec '18

07 Dec '18

The release candidates for the 1.68.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.69.0/source/> The SHA256 checksums are as follows: af05616f71006f97833e130aad886c96136457511ace4b5496d6566e69cbe0ca boost_1_69_0_rc1.7z 8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406 boost_1_69_0_rc1.tar.bz2 9a2c2819310839ea373f42d69e733c339b4e9a19deab6bfec448281554aa4dbb boost_1_69_0_rc1.tar.gz d074bcbcc0501c4917b965fc890e303ee70d8b01ff5712bae4a6c54f2b6b4e52 boost_1_69_0_rc1.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

1 1

Executable files in Boost git repostories
by Edward Diener 06 Dec '18

06 Dec '18

We have again run into the situation where files with a Linux executable permission have been committed to various Boost git repositories, with Jim King creating a PR and list of these files in Boost Admin. I have fixed these for the repositories for which I have write access, and created PRs for the other repositories. But this begs the question as to what Boost's stance should be about adding actual executable files to a Boost git repository ? As an example a Linux bash command file was added to a particular repository and I created a PR to remove the executable file permission from the file. But the maintainer of the repository feels this is wrong and the Linux bash file should retain the executable file permissions and that the file should be part of the repository. But of course I am more interested here about the general principal of the matter. Obviously operating system command/batch files are executable files, but should they be so in a repository. Finally should be not have some sort of git hook that somehow eliminates this recurring problem of files with executable permissions being periodically committed to a Boost git repository ? Most all of the files I "fixed" or created PRs for are clearly source files what can not be "executed" in any way. But this happening again is a real problem to have to clean up each time.

9 22