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

[MPL] A Proposal
by Bruno Dutra 16 Nov '16

16 Nov '16

Dear Community, About a year ago today, there was a proliferation of threads [1][2][3] in this mailing list concerning the future of Boost.MPL, or even whether it had a future at all, and opinions diverged widely on the matter. Many have expressed concerns about the fact Boost.MPL was long outdated and proposed major changes to open path for modernization, while some others argued against it, fearing unexpected and disastrous side-effects could propagate throughout the rest of Boost. A few questioned if it was worth it at all to spend any further resources on Boost.MPL given the fact new alternatives were coming up, such as Boost.Hana, which departed entirely from template metaprogramming, yet some argued TMP remained a competitive alternative for type computations in C++14 as it has been demonstrated by Peter Dimov in his impressive articles [4] on modern TMP. Amidst all this, a proposal by Robert Ramey [5] caught my attention and inspired me to develop what I call Metal [6], a template metaprogramming library designed on the same core principles as Boost.MPL, but written from the very beginning to take full advantage of C++11. Metal was not designed to be a strict drop in replacement for Boost.MPL though, it was rather meant to be regarded as a modern version of Boost.MPL's original API, diverging only where it could really benefit from modern C++ and that essentially means gains of several orders of magnitude in performance** and lower memory consumption. At this point Metal is very close to where I originally intended to bring it and I think it's time I gauge interest from the community on a modest proposal I've been maturing along the past year. As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead. My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them. This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources. Comparing Metal and Boost.MPL there are a few noteworthy differences. Metafunction Classes have proven themselves entirely unnecessary and have thus been removed altogether in favour of pure Lambdas (in the Boost.MPL sense). Moreover, iterators make little sense in a functional world, so these too have been removed despite the fact they may easily be emulated in the new design. Moreover Metal develops the concept of optionals, that is, its metafunctions only have a nested ::type defined when they may be successfully computed, what may be safely tested using metal::is_just and may also be used to SFINAE out of miscomputations. Finally I'd like to point out that Metal was designed to be portable across as many compilers as possible and three of the most popular ones are continuously tested using Travis and Appveyor: Clang 3.5+, GCC 4.8+ and MSVC 14 (2015). I hope this is a reasonable proposal and I look forward into your opinions about it. ** Even though I haven't published any benchmarks yet, an example follows just to back my claims regarding performance (just tested on my personal laptop running linux): //Generate a list containing 10 thousand instances of std::integral_constant, from 0 to 9999 using l = metal::enumerate_t<metal::integer<10000>>; // GCC 5.3 ~0.4 s // Clang 3.7 ~0.5 s //Transform a list containing 5 thousand numbers by squaring each element using l1 = metal::enumerate_t<metal::number<long long, 5000>>; using l2 = metal::transform_t<metal::pow<metal::_1, metal::integer<2>>, l1>; // GCC 5.3 ~5.6 s // Clang 3.7 ~3.0 s [1]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257680 [2]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257983 [3]: http://thread.gmane.org/gmane.comp.lib.boost.devel/258843 [4]: http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [5]: http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ [6]: http://brunocodutra.github.io/metal/ Regards, Bruno Dutra

12 48

interest in structure of arrays container?
by Michael Marcin 06 Nov '16

06 Nov '16

Structure of arrays is a pretty well known pattern for improving memory density and enabling vectorization in high performance code. Also known as parallel arrays[1]. After hand-rolling yet another of these it occurred to me that you make a reasonable first implementation with a simple alias template. template< typename... Ts > using soa = std::tuple< std::vector<Ts>... >; example: soa<int,float,std::string> data; This is decent start but has several issues including: * nothing to preserve the invariant keeping the arrays the same length * missing coalesced interface for vector methods (size, reserve, etc) * no iterator * wasted storage for duplicated allocators, capacities, sizes * sizeof...(Ts) allocations could be a single large block The work required to address these issues is not too great I think. Potential names: soa<Ts> structure_of_arrays<Ts> parallel_array<Ts> struct_array<Ts> parallel_vector<Ts> struct_vector<Ts> Does this already exist somewhere? Does it seem useful? [1]https://en.wikipedia.org/wiki/Parallel_array

10 79

[process] Formal Review starts today, 27 October
by Antony Polukhin 05 Nov '16

05 Nov '16

Dear Boost community, The formal review of Klemens David Morgenstern's Process library begins today, 27th October and ends on 5th November. Process is a C++11 library to manage system processes. It can be used to: * create child processes * setup streams for child processes * communicate with child processes through streams (synchronously or asynchronously) * wait for processes to exit (synchronously or asynchronously) * terminate processes Full documentation with examples and tutorial is available at http://klemens-morgenstern.github.io/process/index.html Stable source codes for review are available at https://github.com/klemens-morgenstern/boost-process/tree/boost_review Latest source codes available at https://github.com/klemens-morgenstern/boost-process We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? We await your feedback! -- Best regards, Antony Polukhin

10 38

Curiousity question
by Edward Diener 01 Nov '16

01 Nov '16

I would like to ask a design question for any Boost developers or anyone on this mailing list who might care to answer. You are designing or working on a library, perhaps for Boost, perhaps for fun, and part of the design of the library has some public functionality taking a shared pointer as input. You: 1) Use boost::shared_ptr 2) Use std::shared_ptr 3) Use both boost::shared_ptr and std::shared_ptr with the same functionality 4) Use neither, you roll your own shared pointer-like functionality 5) You don't lke shared pointers and use raw pointers instead I really am curious about this. I haven't put any limitation on your library or made any presumption on who your library is for, on purpose. Thanks for anyone answering !

13 53

[process] Formal Review starts today, 27 October
by Remi Chateauneu 31 Oct '16

31 Oct '16

Hi All, "Whether you believe the library should be accepted into Boost" It could be, but as some very important features are missinge, the implementation should be prepared from now on. "Your knowledge of the problem domain" About 20 yrs C++ development Linux and Windows. This library has a strong focus on the streaming which is quite rare and interesting. However, other very important features of multi-processing are missing should be planned: At least to ensure that, in the future, they can be added without breaking existing code. Example of these desired fatures are (Taken from my own needs) * List of subprocesses of a given process. * Get its parent pid (Already discussed). * Get the entire process tree of a machine. * It is very useful to be notified when a given process dies (unotify on Linux). * On windows, we have the feature e.startup_info.dwFlags = STARTF_RUNFULLSCREEN, which gives some control on the console, which Is very good. Could we have more documentation about it, and plans to have the same feature on Linux ? Generally speaking have some control on the process terminal if there is one. * Have some knowledge about users and user groups, as strings and integer identifiers: the concept is similar on Windows and Unix. * Have some control on process priority( Unix's nice command ) Indeed, many of these features are not portable, but most of time, developers use only a common core of features, which is quite enough. Maybe take inspiration from portable libraries such as Python psutil, which exposes a common interface for all operating systems. Interoperability: * It might be worth checking portability with other operating systems. BSD ? VMS ??? * Must ensure that this lib is interoperable with boost::interprocess (Concept of permissions might be worth using ?) * Does it build on pre-C++11 compilers ? Many projects are not able to upgrade to C++11 immediately and have to stick to previous C++ standard. Some critics (Nothing is perfect): * The merit of the ">" operator for optional arguments is to be visually similar to an indirection, but in the context of C++ programming, although elegant, it is I think confusing and could be mismatched with <> templates or comparisons. Creating a process is a not-so-frequent operation and we should not be afraid to be verbose and very clear, I believe. * Syntax ‘(bp::std_out & bp::std_err) > "output.txt"’ . Can we explain the exact difference with the syntax: ‘bp::std_out > "output.txt", bp::std_err > "output.txt"’’ * More comments in the code and examples please. * Examples async_io.cpp or arg.cpp do not build with boost 1.62: include\boost\process\detail\windows\compare_handles.hpp(24): error C2039: 'BY_HANDLE_FILE_INFORMATION_': is not a member of 'boost::detail::winapi' * ‘typedef basic_environment<wchar_t> wenvironment;’ : Is It really useful ?? POSIX getenv() only uses char. * Why is the class basic_environment so big, as it is basically a simple std::map< std::string, std::string > ? (Naïve question). Anyway, many congratulations for this very interesting work, which is definitely on the right direction. Regards

2 1

[gil] Some documentation links broken
by Edward Diener 31 Oct '16

31 Oct '16

In the documentation for Gil the links to the video tutorial, as well as the Information links on the left hand side of the initial page, are broken. Does anybody know if these links still exist anywhere ?

1 0

libstdc++ debug mode
by Robert Ramey 31 Oct '16

31 Oct '16

Back on May 2 2016 I made what I thought was an innocuous change to the serialization library build. I then forgot about it. I ran my tests and normal on my OSX set up for the compilers that I use there - clang and g++ 5.1 in various modes 03, 11 etc. Things seemed fine. I uploaded the develop branch as normal. Sometime later I discovered that all the gcc tests on linux platforms were failing with a segfault. Unfortunately time had passed and I couldn't run the tests myself so I never could figure out what the breaking change was. Lately I separated time to get to the bottom of this and in installed via Parallels ubuntu v 14 on my Mac as a guest operating system. After the usual back and forth getting stuff to work I was able to reproduce the problem. Running gdb indicated that things crashed with a call to boost::io::state_saver which led me to investigate THAT library which as it turned out is also failing all it's tests on the plaform. So thought I - no problem - all I have to do is to complain to the author of that library. But this didnt' workout a) I posted message and no one responded. b) I checked trac items and there was what seemed a related item. But it seemed a little hard to understand/fix and in any case, no one addressing it. I looked into just fixing it myself, but it looked to entail delving into the bowels of libstd++. So this dissuaded me as I have my own bowels to delve into. c) So I commented out references to boost::io::state_saver an ran some tests - and damn still failed. d) So I rolled back my source to the master dated 24 April 2016 and incrementally updated and ran some tests until I found the culprit. Needless to say, this is quite a tedious procedure. The issue seems to be that I added the following to the jamfile: <toolset>gcc:<define>_STLP_DEBUG <toolset>gcc:<define>_GLIBCXX_DEBUG The second adds a lot of checking. commenting this permitted tests to pass. Lesson of all this is: a) I'm thinking we should run all tests on the deelop branch with _GLIBCXX_DEBUG defined. That is, our jam files should contain?: <toolset>gcc:<variant>debug><define>_GLIBCXX_DEBUG b) it looks like when an error in libstd++ is encounted - things just segfault. I couldn't find the corresponding source in libstd++. GDB just bailed when I made a call to state_saver. c) boost::io::state_saver should be maintained. d) It would be helpful to be able to roll back the test matrix to any previous git version. That is, the results would be put into a database or datacube and we could scroll back and forth to see track down problems in test results. Robert Ramey

3 3

Review Manager needed for stacktrace library
by Antony Polukhin 27 Oct '16

27 Oct '16

Hello, Stacktrace is a C++98 library for storing and printing backtraces. Supports major platforms, does demangling, has API for accessing individual frames, supports hashing and comparison operators. Library: https://github.com/apolukhin/stacktrace Docs: http://apolukhin.github.io/stacktrace/index.html Anyone wishing to become the Review Manager for the library? -- Best regards, Antony Polukhin

8 21

[preprocessor] PR decision for Intel C++ 17 on up on Windows
by Edward Diener 27 Oct '16

27 Oct '16

I need some guidance from Boost developers in general. A PR has been issued for Boost PP which only affects Intel C++ 17 on up in Windows. I can ascertain that only this compiler in Windows is affectd by the PR. Needless to say I do not test this personally because it costs a decent amount of money to buy a license. Intel does graciously offer free licenses for Intel C++ on Linux for Boost developers and I have used it to test the compiler under Linux. Also there are no regression tests for Intel C++ on Windows in the 'develop' or 'master' regression test matrices. While the person who issued the PR ascertains that it fixes problems for Boost libraries he uses with Intel C++ 17 on Windows the nature of the PR is drastic enough that it could easily break other libraries if the changes in the PR does not correspond to Intel C++ preprocessing in all cases. So my quandary is what to do about the PR. The PR is at https://github.com/boostorg/preprocessor/pull/9#issuecomment-256741882. It is another one of these cases, like clang targeting VC++, where a compiler implementation on Windows wants to emulate the non-standard VC++ preprocessor but can't quite get it right ( as if emulating a broken preprocessor should ever be right ). Thoughts ? Ideas ? Suggestions ?

3 4

Boost odeint 1.62 link broken
by Daniel Duffy 27 Oct '16

27 Oct '16

________________________________________ From: Boost [boost-bounces(a)lists.boost.org] on behalf of Karsten Ahnert [karsten.ahnert(a)googlemail.com] Sent: 16 May 2016 15:08 To: boost(a)lists.boost.org Subject: Re: [boost] Boost 1.61.0 has been released > The Asio link http://www.boost.org/doc/libs/1_61_0/libs/asio/ is broken > (on http://www.boost.org/doc/libs/1_61_0/) I get ERR_TOO_MANY_REDIRECTS > with Chrome. The odeint link is also broken. I get "404 Not Found File "/home/www/live.boost.org/common/code/../../doc/archives/boost_1_61_0/libs/numeric/odeint/doc/html/index.html" not found. Unable to find file." Karsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1