- Boost - lists.preview.boost.org

[Boost] file transfer
by vikram.smvdu 31 Jul '17

31 Jul '17

I recently started learning asio. Documentation is very awesome. I am planing to make a server where there is a file base. And client can login or connect and access the file.. is this possible. I am unable to send data from client to server.. server can sent but vise versa is not implemented by me.. i am trying.. if any body can point me a direction.. it will be much helpful Thank you Regards V Sent from Samsung Mobile

2 1

[BB++] 5 minutes long documentary
by Phil Bouchard 31 Jul '17

31 Jul '17

Like I promised, here's a 5 minutes long documentary on BB++: https://youtu.be/vXmddU_FS30 Regards, -Phil

2 3

CMake and Boost Build tests
by Edward Diener 31 Jul '17

31 Jul '17

Following John Maddock's appeal for practical solutions related to the move to CMake, I would like to know what the CMake equivalent is to the Boost Build unit test functionality. In other words what do I write for CMake in order to do a Boost Build compile, compile-fail, link, link-fail, run, and run-fail unit tests ? Does CMake have an equivalent to the Boost Build alias rule ? or the Boost Build project rule ? The great majority of the Boost libraries are header-only libraries where Boost Build is used to run the unit tests and, optionally, Boost Build is used to build the documentation using a quickbook, boostbook, doxygen toolset to generate html and pdf files. While I realize that building a Boost library, and making that built library available to end-users via CMake, has been the focus of most of the discussion so far regarding CMake and Boost, I am assuming the move to CMake also means that running unit tests and building docs where applicable must also be done through CMake. If I am wrong about this then I personally will be only too happy to continue using Boost Build to do these things.

14 47

[GitHub] Can boostorg/do-not-use be safely deleted?
by Louis Dionne 31 Jul '17

31 Jul '17

We have this repository: https://github.com/boostorg/do-not-use. The description says Permissions experiments; will disappear without notice. I'd like to confirm that this can safely be removed before I go do it. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/GitHub-Can-boostorg-do-not-use-be-safely… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 4

Dependency report
by Peter Dimov 31 Jul '17

31 Jul '17

I haven't run one of these in a while, so here it is. http://pdimov.com/tmp/report-develop-6db78a0a6/module-overview.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html http://pdimov.com/tmp/report-develop-6db78a0a6/module-weights.html We have one "supermodule" at level 5 and another at level 13.

7 33

Boost tests with cmake
by paul 30 Jul '17

30 Jul '17

Hi, So, I have made a small demo setting up the tests with cmake, here: https://github.com/pfultz2/boost-cmake-demo/tree/bcm-test-demo This builds and tests the libraries for Boost.System, so it includes: * assert * config * core * predef * static_assert * system * winapi There are no tests for winapi right now, because I don't have a windows machine to test on(but I suppose I could've tested with mingw). This uses the BCM modules to provide common functionality for building and tests. All the tests are setup to run through CTest, and some targets are provided for building the tests. A `tests` target will build(but not run) all the tests. The `check` target will build and run all tests. Since we do want to filter tests by library, all tests are added with the label of the project name(which can be filtered with `ctest -L <label>`). Furthermore there are targets `tests-<project-name>` and `check-<project- name>` that will build and test a single project respectively. So if we are only interested in the tests for `boost_assert` we can run: cmake --build . --target check-boost_assert And this will build and test `boost_assert`. Any feedback will be useful as we move forward on adding the rest of the tests to cmake. Paul

7 20

boost::asio::async_read loops infinite with zero byte of received data
by Shailendra kumar 30 Jul '17

30 Jul '17

Hi, I am new to this community, hope I am not breaking any rule by this mail. I am facing some issue using asio async_read . Please help. I am sharing the link of the question shared at stackoverflow. https://stackoverflow.com/q/45358908/5649379 Please help Thanks Shailendra kumar

2 1

How to resolve connection via route in proxy server?
by jupiter 30 Jul '17

30 Jul '17

Hi, I can use boost to query and to resolve TCP connection from a remote server which has a public IP address: boost::asio::ip::tcp::resolver::query query(host, port); resolver.async_resolve(query, boost::bind(&ConnectionClient::handleResolve, this, boost::asio::placeholders::error, boost::asio::placeholders::iterator)); But how can I connect to the remote server which does not have a public IP address, I have to connect it via route from a proxy server public IP address? Thank you. Kind regards.

1 0

Re: [boost] Boost tests with cmake
by Rene Rivera 29 Jul '17

29 Jul '17

Accidentally replied to the wrong target.. Putting it back on dev list.. On Fri, Jul 28, 2017 at 11:27 PM, P F <pfultz2(a)yahoo.com> wrote: > > On Jul 28, 2017, at 11:22 PM, Rene Rivera <grafikrobot(a)gmail.com> wrote: > > On Fri, Jul 28, 2017 at 11:01 PM, P F <pfultz2(a)yahoo.com> wrote: > >> >> > On Jul 28, 2017, at 7:25 PM, Rene Rivera via Boost < >> boost(a)lists.boost.org> wrote: >> > >> > The predef script is incorrect. This < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/test/CMakeLists.txt#L25> >> > is not equivalent to the original < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/test/build.jam#L60>. >> > As the "-DCHECK_VALUE=true" is not passed to compiler in response to the >> > evaluation of '"BOOST_COMP_CLANG > 0.0.0" "BOOST_OS_LINUX == 0"'. It >> needs >> > to try to compile and run one of the programs from here < >> > https://github.com/pfultz2/boost-cmake-demo/tree/bcm-test- >> demo/libs/predef/tools/check>. >> > The test is verifying that both this < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/tools/check/predef.jam> >> > and this < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/tools/check/predef_check.h> >> > work as expected. For cmake you would need still need to test the >> latter, >> > still. >> >> Yes, I need to add a custom function `predef_check` in cmake to support >> this, > > > Right. > > >> although it would be best to do the detection directly in cmake rather >> than through the running the tool > > > Not sure what you mean by that. > > > Because when cross compiling you can’t always run the executable, and > using a host compiler seems it would be give different results than the > target compiler. However, a preprocessor expression can be evaluated > through cmake’s try compile, which will safely work with cross compiling. > Perhaps this is what bjam’s rule does already. > Sorry.. I misspoke. They are compile checks, not run checks. If the compile succeeds (of one of the "predef_check_cc_as_*.*") it needs to add the "-DCHECK_VALUE=true" to the compile and run of "check_value.cpp". But the test data in this case would also need to change if you are going to use a try-compile target. As the b2 code parses out those strings and reformulates them as a -DCHECK=.. compile option. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[concurrent] Fast, lock-based queue implementation
by David Stone 29 Jul '17

29 Jul '17

I have written a new concurrent queue that has a focus on high throughput. You can check it out here: https://github.com/davidstone/concurrent-queue Some highlights of this queue: * The bulk interface is faster than other queues for many common load patterns * Almost any element type is supported with very few requirements * Supports any number of producers * Supports any number of consumers (although it works best with only one) * Can dynamically grow and shrink in memory as needed * The interface allows for very little undefined behavior: for the most part, as long as your special member functions like move constructors do not reference the queue you are inserting into, you are fine * Interface based on the pattern of moving values in and returning values via return, rather than other queues which use reference output parameters * Header-only * Design should be fairly straightforward to verify for correctness * Compiles warning free with a very high warning level on gcc and clang * Does not have any errors under ubsan, asan, or tsan I would like to submit this for inclusion in Boost if people find it interesting and useful, but first I would like to get some feedback on the design, implementation, documentation, tests, etc. I have tested this exact version on Gentoo Linux under clang 4.0 and gcc 6.3.0. I will be testing out Visual Studio 2015 and 2017 in the near future to ensure there have not been any regressions. I have run fundamentally the same queue on Visual Studio 2012 (no longer supported due to C++14 features), Visual Studio 2015 (Windows Server 2008 R2, Windows Server 2012), gcc 4.9.1 (Red Hat 6 under developer toolset 3), gcc 4.9.2 (Red Hat 7), and clang 3.9.0 (Red Hat 7) for several years now with no issues, so it is a fairly mature design.

2 4

Documentation snapshot not cycling
by Joaquin M López Muñoz 28 Jul '17

28 Jul '17

Hi, Looks like the documentation snapshot for develop http://www.boost.org/doc/libs/develop/ was last updated five days ago. Any chance this can be given a rebuild? Thank you, Joaquín M López Muñoz

3 3

[optional] Suggestion for adding an optional_number class
by Viktor Sehr 28 Jul '17

28 Jul '17

I'd like to make a suggestion for adding an optional class for number types, called optional_number, where the max value of the number type is utilized as the uninitalized value. Differences compared to std::optional<int, float, enum etc>: *- No size overhead from the wrapped type* - Theoretically faster (althrough in practice probably negilble) - Can be assigned to any value except the max value - Operator-> is removed as it does not make sense for an integer Notes: - Throws if assigned the numeric_limits<T>::max - Also works with enums, using the underlying_type - The operator bool conversion is missing in the prototype implementation Attaching a prototype implementation (currently for C++14). /Viktor

5 8

Proposal for moving Boost to CMake
by David Sankel 27 Jul '17

27 Jul '17

Howdy all, This is a request for comments on a possible path for migrating Boost's build system to CMake. I am not speaking for the Boost Program Committee here, but I plan on bringing this up with them after getting feedback. The motivation is simple. CMake is currently the dominant player in the area of open-source, cross-platform, C++ build-systems. I make this claim based on Google trends graphs and discussions with others at the conferences I attend (CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and usable out-of-the-box with CMake, we would significantly lower the barriers to entry for both Boost users and new Boost developers. Boost serves the greater C++ community and making Boost more accessible would be of great utility. * To ease the migration path, both Boost.Build (the current jam-based build system) and CMake will be supported for a time. * Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake. A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build. * The built Boost **binaries** would also provide a compatible, drop-in replacement for the 'FindBoost' module distributed with CMake. The behavior is similar to the previous bullet, except the built binaries would be used instead of the source code. * The style of the 'CMakeLists.txt' files would follow current best practice. We'd resist the temptation to write macros which replace the core CMake functions. There would be repetition in the files, to be sure, but I think we should avoid attempting to innovate CMake. I've seen this fail on many occasions and would like to keep our goal focused, at this point, on migrating Boost to CMake. In the future we could revisit this. * There would be a list of CMake guidelines that we'd use. * Boost libraries should be buildable in isolation and use 'find_package(Boost...)' to discover their Boost dependencies. * We would work with CMake towards eventually taking over maintenance of the FindBoost module distributed with CMake. I see this progressing with several milestones. 1. Release of a CMake-buildable Boost and the CMake conventions. In this stage each Boost library can be built in isolation or with the entire distribution and all the 'FindBoost' functionality mentioned above would be incorporated. 2. The unit tests for all Boost libraries are incorporated into CTest (the CMake unit test orchestration tools). 3. The Boost infrastructure is modified to use CTest for unit testing. 4. Unit testing functionality is removed from Boost.Build. 5. Boost.Build is removed. Although there are many other great ideas floating around (e.g. modularization of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on CMakification of Boost because I think it is something that would have big impact and is small enough to be doable. One question that is going to come up is "who is going to do all this work?". Once we decide on a direction, I don't foresee a problem making this happen. Between volunteers, the importance this project has for companies, and the Steering Committee reserves, we should have the resources necessary. Another concern is that some authors may resist. Authors have a lot of leeway when it comes to how they maintain their libraries, what conventions they use, and backwards compatibility concerns. However, there are some things that authors need to conform to, such as our current Boost.Build build and testing infrastructure. I liken this to the development of a city: building developers can make their buildings however they want, but the streets, which control transit between buildings, are centrally regulated. Thanks for your consideration. -- David Sankel

29 140

PGI C++ compiler support
by David Olsen 27 Jul '17

27 Jul '17

Many years ago, Boost was configured to work well with the PGI C++ compiler (http://www.pgroup.com/) But maintenance of the PGI support within Boost stopped about five years ago, and PGI will no longer build Boost without modifications to the Boost sources. I am working on restoring support for the PGI C++ compiler. Many PGI customers want to use Boost, so we at PGI are putting in the effort to make that easy to do. I have already fixed a bunch of bugs in the PGI compiler that were triggered by Boost code. Now it is time to make necessary adjustments to the Boost source. I have created six pull requests that make it possible to build Boost with PGI. https://github.com/boostorg/build/pull/218 https://github.com/boostorg/filesystem/pull/49 https://github.com/boostorg/mpl/pull/30 https://github.com/boostorg/spirit/pull/236 https://github.com/boostorg/type_traits/pull/45 https://github.com/boostorg/config/pull/169 The only big change is overhauling the pgi.jam file. The other changes are just removing an obsolete #if or changing an #if expression. None of the changes should affect any compiler other than PGI. Next I am planning to make any necessary changes to test code and to header-only libraries so that PGI gets decent results when running the Boost tests. Then I will look into setting up a test bot for the PGI compiler here at PGI. -- David Olsen (dolsen(a)nvidia.com) NVIDIA - PGI Beaverton, Oregon

5 6

[type_erasure] link to any_cast reference section
by Joaquin M López Muñoz 27 Jul '17

27 Jul '17

Hi, Unlike most classes/functions in Boost.TypeErasure, the following http://www.boost.org/doc/html/boost/type_erasure/any_cast.html does not go to the reference for boost::type_erasure::any_cast, the proper link being http://www.boost.org/doc/html/boost/type_erasure/any_cast_idp758556752.html Problem is this seemingly autogenerated file name is unstable. For instance, for Boost 1.63 the link was http://www.boost.org/doc/libs/1_63_0/doc/html/boost/type_erasure/any_cast_i… in develop it is http://www.boost.org/doc/libs/develop/doc/html/boost/type_erasure/any_cast_… and in master it is http://www.boost.org/doc/libs/master/doc/html/boost/type_erasure/any_cast_i… which makes it impossible to refer to this section of Boost.TypeErasure documentation from other pages. Maybe this can be fixed? Thank you Joaquín M López Muñoz

2 5

[review][mp11] Formal review of Mp11
by Bjorn Reese 27 Jul '17

27 Jul '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master Please answer the following questions in your review [4]: 1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain? [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html [4] http://www.boost.org/community/reviews.html

18 56

[Signals2] library fails to compile with -fno-exceptions
by Jackie Kay 26 Jul '17

26 Jul '17

The signals2 Git repo does not have issues enabled, so I thought I'd ping the list about this. Trying to compile any program that includes boost/signals2 with -fno-exceptions fails as of 1.64: #include <boost/signals2.hpp> // boost/signals2/slot.hpp will also reproduce the error int main() { } g++ prog.cc -I<path to Boost 1.64.0 headers> -std=c++11 -fno-exceptions View it on Wandbox: https://wandbox.org/permlink/vZVpF5bb8E9K7sDz I was also able to reproduce this locally on the develop branch. It appears this is because the slot_base lock function is not defined when exceptions are disabled, but this is not checked when it lock is called in `slot_template.hpp`. I am working on a fix, but I would like to know what the path moving forward for the fix would be. Signals2 is currently unusable in 1.64 with exceptions turned off.

1 0

Separate Boost CMake mailing list
by Edward Diener 25 Jul '17

25 Jul '17

I think that a separate Boost CMake mailing list would be beneficial, rather than have all the discussion about the move to CMake, as the default Boost build system, as well as further uses of CMake with Boost libraries and tools, on the developers mailing list. This is similar to the way that Boost currently has a separate mailing list for Boost Build.

5 8

Mp11 review
by paul 25 Jul '17

25 Jul '17

Hi, this is my review of mp11. Please answer the following questions in your review [4]: > 1. Should Mp11 be accepted into Boost? Please state all conditions > for acceptance explicity. Yes Mp11 should be Accepted. > > 2. What is your evaluation of the design? Very good design overall. I don't know if I really like the `mp_` prefix. Trailing underscores is common in boost, but the mp prefix makes sense for standardization. It uses the `std::integral_constant`, but it might be nice to use another implementation, as that can help make it consistent between C++11 and C++14. Also, providing an integral constant with operators could help improve interoperability with hana-style metaprogramming(which also help interoperate with the Fit library as well). Of course, I don't know if mp11 is right place for it. It seems it would be better to have a separate library for this and the other C+14 features as well. Also why is `mp_with_index` only constexpr on C++14 and higher? > > 3. What is your evaluation of the implementation? The implementation seems to be good and provides competive performance with other metaprogramming libraries, but I do wonder if some of Odin's metaprogramming techniques(such as recursive aliases) can be used to improve the performance as well. > > 4. What is your evaluation of the documentation? Very well documented and organized. > > 5. What is your evaluation of the potential usefulness of the library? I think this library can be very useful for C++11 metaprogramming where I have needed. I don't think it would be as useful for the Fit and Tick library because they still target gcc 4.6, which mp11 doesn't support due to being based around template aliases. > > 6. Did you try to use the library? With what compiler? Did you have > any problems? Yes, I did, and also ran the tests. I tried to run the tests on some configurations that aren't ran in the travis CI(like clang 3.5 with C++14). And all the tests do pass. > > 7. How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I spent a couple hours reviewing, and I have implement ad-hoc versions of these in my own libraries as well. Paul

1 0

[review][mp11] Reminder of ongoing formal review
by Bjorn Reese 25 Jul '17

25 Jul '17

The formal review of Mp11 continues until (and including) Monday, July 24th. There have been four formal reviews so far. I would like to ask the Boost community for two favours: 1. Please postpone the discussions about CMake and the future directions of Boost until the formal review has ended. 2. Please review the Mp11 library instead. If you disagree with any of the above, please contact me off-list. Here is the call for review once more: The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master Please answer the following questions in your review [4]: 1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain? [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html [4] http://www.boost.org/community/reviews.html

7 12

[review][mp11] Review of Mp11 has ended
by Bjorn Reese 25 Jul '17

25 Jul '17

The review of Mp11 has ended with a total of 12 formal reviews (and one pending.) I would like to thank all who have participated in the review, as well as those who agreed to postpone CMake discussions until the end of the review. The review report will be posted in the near future.

1 0

[config] What Feature is this??
by John Maddock 25 Jul '17

25 Jul '17

Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function. The code I want to enable involves function overloading based on a decltype return type as in: auto integrate(args...) -> decltype(expression1); auto integrate(args...) -> decltype(expression2); where expression1 and expression2 are two mutually exclusive options (the conceptual requirements of args means that only one of these 2 will ever be satisfied). This works fine in msvc-14 and later and gcc-4.8 and later, but I don't see any current config macros which cover this case, nor can I figure out what this trick should be called. Alternatively, if anyone has a better way of differentiating between unary and binary functions I'm happy to hear about it ;) Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

6 13

[review][mp11] Formal review of Mp11
by Glen Fernandes 25 Jul '17

25 Jul '17

What follows is my review of the Mp11 library: [Should the library be accepted into Boost?] Yes. I vote for an unconditional ACCEPT. [What is your evaluation of the design?] Excellent. The design where any template can serve as a list, and any template can serve as a meta-function is both elegant and powerful. The additional quoted meta-function support with utilities such as mp_bind, mp_bind_front, and mp_bind_back, addresses the other request I had when reviewing an earlier version of Mp11. While HOMF were never essential, as the article pointed out, users appreciate more ways to one-line things without having to write a helper type. Some additional primitives are desired, as mentioned later in this review (e.g. min and max functionality) but overall the toolkit is already vast and useful. [What is your evaluation of the implementation? Excellent. The focus on performance is definitely appreciated while we still have to depend on libraries for many of these meta-programming primitives. Ideally many of these would be provided in the standard library and have implementations that only a compiler vendor could provide with built in support, and offer performance beyond what a library could offer. In the meanwhile, the performance offered by Mp11 is great, more than sufficient for my needs, and in my opinion also for the majority of users. In comparison, the tiny C++11 meta-programming library that I have implemented, uses only the obvious C++11 implementations for most functionality, and does not offer the same fast compile times as the equivalents in Mp11. The techniques used by Mp11 via C++11 constexpr, C++14 constexpr, and even C++17 fold expressions, besides improving Mp11 performance, were a valuable source to learn from. Suggestion: Can all the workarounds for MSVC versions 1800 and older for the empty list cases be avoided by instead using a helper trait? i.e. template<template<class...> class L, class... T, template<class...> class P> struct mp_find_if_impl<L<T...>, P> { using type = typename mp_find_if_impl_2<P, T...>::type; }; i.e. Introduce mp_find_if_impl_2 which would then have the obvious implementation as before, only without requiring the MSVC workaround? This is only worth considering if you find it to offer some benefit such as: Additional maintainability of the Mp11 code, with less workarounds, and no costs, e.g. no increase in compilation times as a consequence. [What is your evaluation of the documentation? Very good. The reference documentation is clear, and easily understood. More example and tutorial content before the reference section would always be welcome, but not necessary. Suggestion: The two-part article that Peter wrote (which is referenced in the documentation) is in my opinion so valuable for users to gain better understanding and appreciation of the library that it should be included in the library distribution as part of the documentation. Ideally in the same Asciidoc form as the current documentation, as a supplemental document (or Appendix entry). Suggestion: Does it make sense for the documentation to have a section describing the conventions the library uses, for potential contributors as much as users? e.g. If someone was designing an mp_min_element, should it yield the element type result, or the list index size constant result? Is there an established convention of when an error is acceptable for an empty list versus returning an index? Correction: Under heading mp_find_if<L, P>: "mp_find_f<L, P> is an" should be "mp_find_if<L, P> is an". [What is your evaluation of the potential usefulness of the library? Incredibly useful in its current form, and this is only going to increase as the library is extended based on user requests for additional functionality. Almost every meta-programming primitive that I have needed recently either already exists in Mp11, or I am able to implement using Mp11 with a little effort. During this review I replaced the use of my own meta-programming library in a project of mine without any issues. As part of this review I also tried several exercises where I implemented certain traits and meta-functions using Mp11. Of all the exercises that I attempted, the only one where the library lacked the necessary utility was an "mp_min_element" function: This was an implementation of the typical "type_with_alignment" trait, which can easily be implemented using a "min_element" functionality. Mp11 does not have mp_min, mp_max, mp_min_element, mp_max_element presently, and I believe they should be added because they are useful and users will probably find themselves implementing it. Sure, mp_sort exists, but I would not use a sort when a min_element can suffice. In this case, type_with_alignment<N> could use mp_min_element with a predicate that finds the type in an mp_list of several scalar types, that matches has an alignment of at least N and has the smallest size, and then check that the result element type of the mp_min_element is at least N. The litmus test for me for a meta-programming library is the question: Would I use Mp11 in library code? The answer for me is "yes". If it was part of Boost, I would use it in other Boost libraries (that already require C++11 or higher). [Did you try to use the library? With which compiler(s)? Did you have any problems?] Yes. I used the library as a replacement for an existing meta-programming library of mine in real (non-toy, non-exercise) project code that is compiled with g++ 4.8.5 in c++11 mode for x86 and x86_64 Linux, using Boost 1.64.0, on 64-bit RHEL 6 and measured compilation times. I also used the library in a few exercises that I compiled with g++ 7.1 and clang 4.0.0, for x86 and x86_64 Linux, using the current Boost master branch, for c++11 and c++14, on 64-bit Fedora 26, and again measured compilation times. I also compiled and ran the Mp11 unit tests with the compilers, C++ standard modes, architectures, Boost distributions, and operating systems mentioned. [How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?] More than ten hours over this weekend reading the documentation, reviewing the implementation and tests, using Mp11 in a project replacing my own C++11 meta-programming library, using it in various exercises, and running the Mp11 unit tests with the various compilers, C++ standard modes, targets, and Boost distributions listed above. Prior to the preparation for the review, I had spent some time with an earlier version of Mp11 and comparing it to Metal for implementing a few meta-functions, including the "instantiates_" example from my library: instantiates_<T, templates_<std::set, std::multiset, std::unordered_set> > Where instantiates_ should be implemented in terms of "is_instantiation_of_": is_instantiation_of_<T, std::set> Which has the obvious behavior indicated by the trait name. The Mp11 approach provided by Peter for this case, and the relative ease with which I was able to implement the other meta-functions using Mp11 were a convincing demonstration of the usefulness of the library. [Are you knowledgeable about the problem domain?] Like many of us, I had written a meta-programming library as C++11 language features have become available. Before that, if Boost.MPL solved a problem, more often than not it was convenient and useful enough to just use it, even if writing my own implementation would result in faster compilation times. Peter's article, however, opened my eyes to a more elegant design, and changed how I implemented my C++11 meta-programming library, and in general shaped what I think about meta-programming in modern C++. Thank you Peter for your work on Mp11, for submitting it for inclusion in Boost, and for the articles that motivated it and taught the rest of us. Glen

6 5

[BB++] Now fixes all of your memory leak nightmares
by Phil Bouchard 24 Jul '17

24 Jul '17

Greetings, Now I have an example showing off the cyclic reference handling. Please see: https://github.com/philippeb8/root_ptr/blob/bb++/bbpp2cpp/tests/input2.bb This program correctly outputs: Document::Document(const boost::node_proxy&) auto __0(boost::node_proxy&, int) 1 Document::Document(const boost::node_proxy&) Document::~Document() 2 Document::~Document() So I just came to realize we could use this tool to parse entire projects to generate the right C++ code, after having disabled the 'operator delete', and then run the executable, which still is 3.5x faster than Node.JS. For the newcomer please see: https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp I am going to present this to NASA and company. Meanwhile anybody is welcome to help me out extending the parser to support template syntaxes. Regards, -Phil http://bbplusplus.com/

4 6

[asio] windows service async server crashes after running for a while; though it works fine from console
by Kyoryu Kurayami 24 Jul '17

24 Jul '17

I have an existing console async server that I converted to a windows service. After running for a while (about 1-2 hours), the service would eventually crash caused by stack overflow on different parts of the code (been trying different approach on the code that causes the stack overflow exception but to no avail as it would still crash on a different location) Now, I have been wondering if an async server approach is really suitable for a windows server or should I then opt to convert it to synchronous instead. I used the combination of *io_service::reset()* and* io_service::run() *to block the current code as I've read somewhere that thread running the *io_service::run()* shouldn't immediately exit if it is running as a windows service. Do note that my previous implementation was just calling the *io_service::run() *on another thread, but this doesn't seem to work as per the explanation and solution mentioned above.

2 1