- Boost - lists.preview.boost.org

[python] Checking Python version
by Edward Diener 18 Oct '18

18 Oct '18

How do I check the Python major version in code when using Boost.Python ? I know there is a way to do it through a preprocessor define by including the CPathon patchlevel.h file but I would rather not include low-level Python files if Boost.Python has some way of doing it.

2 1

[test] How to execute shell commands
by Mike Dev 18 Oct '18

18 Oct '18

As an extension to my previous question: Does the boost test framework provide an integrated mechanism to get the binary directory (the directory where the currently running test executable is placed) and/or the source directory (where the jam-file resides that defined the test)? Best Mike

4 5

[intrusive] static_assert(sizeof(caster)==sizeof(int))
by Vinnie Falco 18 Oct '18

18 Oct '18

A user is reporting a static assert on compilation: <https://github.com/boostorg/beast/issues/1270> Any ideas? Thanks

2 1

Boost header isolation testing
by James E. King III 16 Oct '18

16 Oct '18

In the winapi project there's a neat little Jamfile rule that will ensure each public header will compile properly (i.e. it is not missing any #include statements). I pulled this into uuid when I started maintaining it, and I find myself pulling it into another repository. It would be nice to have this as a standard Boost.Build rule that one could easily add to test Jamfiles. Is there anything like this that exists right now in Boost.Build? - Jim

6 9

Boost CMake support - Request for Comment
by Robert Ramey 16 Oct '18

16 Oct '18

Background ========== My personal knowledge of build systems is somewhat limited. a) I don't really understand CMake all that well. I have made CMakeLists.txt files for both the serialization library and the safe numerics libraries as an aid to build and maintain IDE and make files used in running tests and posting results to CDash. b) I don't really understand our current system, Boost Build, very well either. I've made jam files for building and running tests for the serialization and safe numerics libraries. c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video from C++Now 2017 “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly. Despite my lack of knowledge in this area, or perhaps because of it, I've volunteered to direct the effort to evolve Boost so that users of Boost can avail themselves of the benefits of CMake. This effort will be organized as follows: a) A discussion on the boost developers mailing list with the goal of reaching a consensus as to what benefits CMake can and should provide to users and developers of Boost. This effort will commence with the posting of this notice. I hope that this discussion can be more or less resolved within 30 days. b) I will then synthesize from the above discussion a call for proposals which lists the requirements and requirements. c) Those proposing CMake for boost will have approximately 90 days to prepare their proposals. Their proposal are expected to look similar to a boost library proposal. That is they are expected to have some (CMake) code, along with tests, documentation including tutorials and reference. This is only an expectation. It's conceivable that such a proposal might only contain conventions and and samples of what boost library should contain to fulfill the requirements. As with boost libraries, submissions are not required to totally complete. But they have to be sufficiently complete to convince reviewers the the submission fulfills the stated requirements and can be finished in good time. d) After the 90 day period, submissions will be reviewed simultaneously. Note that this is at a variance from normal boost procedure of reviewing submissions one at a time. Since we expect to receive a number of submissions and only one can be accepted, the normal boost protocol can't really function. Target date for this review is 1 February 2019. e) After the review period the review manager will prepare a report which includes the decision of which submission will be accepted into the official boost distribution. Currently, I, Robert Ramey, expect to be review manager. However, it's possible that this by the time the review is undertaken, this coveted position could be assigned to some more worthy candidate. Scope, Requirements and Features ================================ We presume that submissions will fulfill the applicable requirements of any boost submission. In addition we would like to see the following addressed. Library Build ------------- “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk Recommends that all libraries - including header only libraries have a CMakeList.txt file. What should this include for Boost Libraries? Library Test ------------ Should facilities for "testing" be only done by developers? or should users who acquire library packages also be able to test libraries. Should CMake testing results posting be used - CDASH? Should we just skip the issue of Library Testing and continue to depend on Boost Build. Library Packaging ----------------- Is the library packaging facility provide by CMake - CPACK - useful to boost. Should boost libraries be updated to support it? Dependencies ------------ If the above is implemented, can we depend upon CMake to handle library dependencies? Or does some special functionality Do circular dependencies constitute a problem? Modularity ---------- Currently boost is organized as a tightly integrated group of libraries. This organization manifests itself in a number of ways. We have a Boost "super project" in github. Boost libraries are "sub projects" of this super project. This known structure is exploited by and depended upon by boost tools. Should CMake support continue this policy/design. We distribute boost as "super project". Should we continue to do this or distribute libraries on a library by library basis. Does CMake/CPACK etc. make this "simple"? Documentation/testing --------------------- What support should be require for uses of Boost CMake implementation. Documentation, examples, templates for helping library developers. How should the CMake design/implementation be tested? Other considerations -------------------- add your requirement/features here. Useful Resources =============== “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 https://github.com/purpleKarrot/Boost.CMake https://www.youtube.com/watch?v=eC9-iRN2b04 Please try to keep this discussion on this list. I know that there has been a lot going on on slack. But having it in two places makes it harder for me to review and summarize. Also slack doesn't conveniently maintain comment hierarchy. So please try to keep this discussion on this list. Robert Ramey

15 47

Re: [boost] "peer reviewed" - Rights and responsibilities of maintainers
by Bjorn Reese 16 Oct '18

16 Oct '18

On 10/16/18 9:59 AM, Alexander Grund via Boost wrote: > So again: What is the Boost course on reviews of existing libraries and > the statement on the rights and responsibilities of maintainers? https://www.boost.org/community/reviews.html#Maintainer

4 4

[program_options] custom validator overrides
by Roger Martin 16 Oct '18

16 Oct '18

Hi, The Custom Validators documentation https://www.boost.org/doc/libs/1_68_0/doc/html/program_options/howto.html shows void validate(boost::any& v, const std::vector<std::string>& values, magic_number* target_type, int) { but the possible templates don't match; the last variable type is an int; the key is matching this last type: int goes with std::vector<T>* long goes with T* it also seems possible to hit the void validate(boost::any& v, const std::vector<std::basic_string<charT> >& s, boost::optional<T>*, int) { where it then calls for get_single_string and if you are trying for a multitokens switch args, it'll throw " only takes a single argument". which also varies if it was parsed by command_line_parser or parse_config_file command_line_parser: vector size can >= 1 up to number of switch args parse_config_file: vector size ==1 no matter what the number of args are on the input. just one string with all switch args. This was tested with 1.65 yet I don't see anything changing in https://github.com/boostorg/program_options/blob/develop/include/boost/prog…

2 1

[RFC] unique_val (handles, IDs, descriptors...)
by Miguel Ojeda 15 Oct '18

15 Oct '18

Hi all, While working on a medium-sized project, I had to wrap quite some handles, IDs, descriptors, etc. into RAII classes. Somehow, writing those and making them movable seemed more verbose than needed. I searched in the STL and Boost for something already implemented, but nothing seemed to come up. I decided to write my own prototype to see whether I was missing something important; but actually using it in my project felt quite natural and simple. At this point, I asked for a second opinion from a well-known expert (thanks Scott!) and he agreed that it seemed like a reasonable idea but, of course, he would also be surprised if others haven't come up with something similar. So I polished it up a bit and uploaded it to: https://github.com/ojeda/unique_val Below you have the introduction inlined [1]. If you have the time, please take a look (specially to the Rationale) and let me know your comments. The code itself is very short and straightforward. If you already have this class/template in Boost somewhere that I missed, please let me know! Otherwise, if you think this could be interesting to put into Boost in some existing library (not sure which) or as a new tiny library, I would be glad to make the effort to expand it, clean it up, etc. Thank you! Miguel [1] """ A single-header header-only library for representing unique values (handles, IDs, descriptors...) that default to a value on move for C++11, C++14 and C++17. It simplifies writing resource-owning classes (RAII) with move semantics support for resources with handles, IDs or descriptors that are supposed to be used as unique values, not as unique pointers. For instance, it can be used with non-pointer handlers (like the `int` file/socket descriptors in POSIX) and with opaque pointer handlers (like the `HWND` handles in the Win32 API). As such, it can be used as an alternative to `std::unique_ptr` with or without custom deleter, specially for resources that use a non-pointer type or resources that are not simply heap-allocated. It does not have any overhead compared to using the original type. It supports booleans, integers, pointers and enumerations. The default value can be different than the default-constructed value (i.e. different than 0, nullptr, etc.). """

7 13

bjam question about "requires" negation
by James E. King III 13 Oct '18

13 Oct '18

I want to run a test that should run without explicit operator conversion capability and fail to compile with explicit operation conversion capability, but I'm not sure how to negate the requires statement. I'm sure it's trivial but I found no examples. I tried a bunch of things but none worked. [ run implicit_conversion.cpp : : : [ requires NO cxx11_explicit_conversion_operators ] : implicit_conversion ] [ compile-fail implicit_conversion.cpp : [ requires cxx11_explicit_conversion_operators ] : explicit_conversion ] How do I properly implement the "NO" part? Thanks, Jim

2 1

[parameter] An offer to help maintain and improve the library
by Cromwell Enage 13 Oct '18

13 Oct '18

Hello, everyone. It took me a while to get around to this, but here goes. I've been a long-time user of Boost libraries, although life events imposed a bit of a hiatus until recently. But now I have the opportunity to help out some more, and one of the ways I want to give back to this community is by helping to maintain and improve Boost.Parameter. I participated in the review of this library before it was accepted, so I'm familiar with its capabilities and code structure. In addition to fixing any bugs and handling pull requests, I'd like to make the following improvements, which I will summarize here: * Add macros to generate Boost.Parameter-enabled function call operators. * Add parameter category qualifiers "consume", "move_from", and "forward". (Current qualifiers are "in", "out", and "in_out".) * Fix parameter::parameters::operator() so that it also accepts non-const rvalues. * Be no longer bound by BOOST_PARAMETER_MAX_ARITY on compilers that support perfect forwarding. * Enable parameter::template_keyword<> to accept function types. * Remove the necessity of wrapping boost::ref() around non-const lvalues. I can discuss each of these bullet points in separate threads if necessary. I await your feedback! Cromwell D. Enage

2 1

Boost xxhr ? High level http client library
by Damien Buhl 13 Oct '18

13 Oct '18

Dear Boost, I've built an header-only library based on Boost.Beast which allows you to perform HTTP requests. It is implememented with two backends : * Boost.Beast for native builds. * XmlHttpRequest for WebAssembly (plans to migrate to fetch API which is richer) Actually Boost.Beast is a great lib, however it's API is thought to build HTTP centric app not just to make some simple HTTP call ( as for example urdl was ). xxhr on the other hand is about making it simple to call an HTTP service. Usage example : GET <https://nxxm.github.io/xxhr/html/namespacexxhr.html#a69bafa24d7c33b004a7de8…>( "http://httpbin.org/anything"s, on_response = [](auto&& resp) { std::cout << resp.text; }); I would be really interested in a pre-review or some feedback about it's API. The implementation merits more attention and can significantly be improved but this email is to grab a first feedback from the community. Documentation : https://nxxm.github.io/xxhr/ GitHub : https://github.com/nxxm/xxhr Example code relying on it : nxxm/gh <https://github.com/nxxm/gh>: partial GitHub API implementation Thanks for your time :) -- Damien Buhl Software Developer +33 6 77 43 10 05 https://nxxm.github.io/

3 5

Test matrix file read errors?
by James E. King III 11 Oct '18

11 Oct '18

I'm trying to look at the develop test matrix for a couple repositories and I am getting an error: Error extracting file: Error code 9 - The specified zipfile was not found *(the > file exists, so this is probably an error reading the file)*. https://www.boost.org/development/tests/develop/developer/date_time.html https://www.boost.org/development/tests/develop/developer/dynamic_bitset.ht… Thanks, Jim

2 1

[concept_check] CopyConstructible Concept Does Not Accept Lvalue Reference
by Qu Xing 11 Oct '18

11 Oct '18

Boost version: 1.67.0 Compiler: GCC 7.3.0 Environment: Cygwin on Windows 10 version 1709 In the Boost Concept Check library, CopyConstructible concept requires operator & applicable to the type being checked, and the return value is required to be convertible to pointer to the type. However, pointer to reference is not allowed in C++. This concept check fails to compile if applying to a lvalue reference type. On the other hand, is_copy_constructible<T> type trait class in the Boost Type Traits library and the standard C++ library both give positive result on lvalue reference types. For example, the following code snippet will fail to compile if T is a lvalue reference: #include <type_traits> #include <boost/static_assert.hpp> #include <boost/type_traits/is_copy_constructible.hpp> #include <boost/concept_check.hpp> #include <boost/concept/assert.hpp> template <typename T> void RequireCopyConstructible() { BOOST_STATIC_ASSERT(boost::is_copy_constructible<T>::value); // PASS on lvalue reference BOOST_STATIC_ASSERT(std::is_copy_constructible<T>::value); // PASS on lvalue reference BOOST_CONCEPT_ASSERT((boost::CopyConstructible<T>)); // FAIL on lvalue reference } void TestReference() { RequireCopyConstructible<int&>(); } Diagnosis message is generated as: "error: forming pointer to reference type ‘int&’". I think the operator & applicable requirement should be removed for CopyConstructible concept. Alternatively, adding a template specialization on lvalue reference type for CopyConstructible concept may work as well.

1 0

[config] really, really sticky issue with BOOST_SYMBOL_IMPORT
by Robert Ramey 10 Oct '18

10 Oct '18

For many, many years we've built the Boost serialization library with the macros for BOOST_SYMBOL_IMPORT and BOOST_SYMBOL_EXPORT set according to the instructions included in the boost/config documentation written by John Maddock. These set attributes for creating and using DLLS for windows and (used to) resolve to nothing on other systems. So far so good. At some point things changed for gcc compilers. Now it seems that BOOST_SYMBOL_IMPORT resolves to nothing and BOOST_SYMBOL_EXPORT resolves to : __attribute__ ((visibility("default"))) and BOOST_SYMBOL_IMPORT still resolves to nothing. OK - this has never been a problem. Now we have an extremely subtle issue which appears on linux systems with gcc. It's related to sequence of shared library loading and unloading. It shows up as a bunch of test failures for the test named test_exported_dll. A very astute user has determined that this can be "fixed" by defining BOOST_SYMBOL_IMPORT as __attribute__ ((visibility("default"))) as well. Question. should config/gcc be updated in this way? Also is it possible that this "fix" is just a fluke unrelated to the real source of the problem? Note that this issue predates the recent change to make -visibility=default which has, as one might expect, caused some issues. I believe that this situation is unrelated. Any help appreciated Robert Ramey reference: https://github.com/boostorg/serialization/issues/104#issuecomment-416948110

4 3

Tools to manage multiple repositories effectively?
by James E. King III 09 Oct '18

09 Oct '18

Hello, I am looking for tools that would allow me to create a portal and/or monitor the following properties of boost repositories. I am in the CMT and at least one fix that was in develop never made it into master for the 1.68.0 release, so I want to be able to see, at a glance, information about the boost repositories I care about in one place. There are about 20 repositories I regularly participate in now so a portal to show what I need to worry about would be useful. 1. How far behind is master (with respect to develop)? This would help identify which repositories are behind develop. Useful for ensuring things get into a release. 2. How many open pull requests? 3. How many new pull requests (within the last week)? 4. How many updated pull requests (within the last week)? 5. How many open issues? 6. How many new issues (within the last week)? 7. How many updated issues (within the last week)? "week" could be configured, perhaps month, or "since I last visited". Anybody know of any good tools or perhaps an existing site that can do this for a multi-repository solution? Thanks, Jim

3 2

[system] The new Boost.System is now ready
by Peter Dimov 09 Oct '18

09 Oct '18

The new Boost.System is now complete, on the develop branch: https://www.boost.org/doc/libs/develop/libs/system/ - header-only - even more constexpr than 1.68 - identifier-based category comparison - message() into a caller-supplied buffer - failed() The plan is to merge it to master at some point if no breakage is encountered on develop, so that it can go into the next release.

5 11

Export control classification number for boost
by DEMIAN, Beatrice (SOPRA STERIA GROUP SA) 08 Oct '18

08 Oct '18

Hi, We are using boost in one of our products, and are now in the process of collecting the information needed to export it. Can you tell me what the U.S. Export Control Classification Number (ECCN) for boost is, and whether a license exception may be used for it? Béatrice Demian On behalf of SOPRA STERIA Subcontractor for EYYW6 (AIRBUS France) The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

2 1

[graph_parallel] property_serialize.hpp
by Peter Dimov 06 Oct '18

06 Oct '18

I'm looking at boost/pending/property_serialize.hpp, with the intent of moving it from Graph Parallel to Graph as it's included from a Graph header, and I see this: https://github.com/boostorg/graph_parallel/blob/develop/include/boost/pendi… #ifdef BOOST_GRAPH_USE_MPI namespace boost { namespace mpi { template<> struct is_mpi_datatype<boost::no_property> : mpl::true_ { }; } } // end namespace boost::mpi BOOST_IS_BITWISE_SERIALIZABLE(boost::no_property) BOOST_CLASS_IMPLEMENTATION(boost::no_property,object_serializable) BOOST_CLASS_TRACKING(boost::no_property,track_never) #endif // BOOST_GRAPH_USE_MPI What this does is, when BOOST_GRAPH_MPI is defined, it sets certain serialization properties for boost::no_property (is bitwise serializable, use object level versioning, never track address), but when BOOST_GRAPH_MPI is not defined, it doesn't. That is, the serialization format of boost::no_property changes on the basis of whether BOOST_GRAPH_MPI is defined. (It's the same for boost::property<>, above in the same file.) This does not seem correct to me. I would expect these serialization properties to be applied consistently regardless of whether MPI is used or not. But fixing this could conceivably break existing code that serializes and deserializes non-parallel graphs and relies on a certain format on disk. So... should we fix this or not?

2 2

Cycle between Graph and GraphParallel
by Peter Dimov 06 Oct '18

06 Oct '18

Currently we have a dependency cycle between `graph` and `graph_parallel`. It's not the only one, but it's notable with the fact that both libraries are buildable and we therefore can't ignore it as we can ignore cycles between header-only libraries that at release time become a single directory. In the particular, this impedes efforts to generate CMake config files. Under one scheme I'm currently working on, for instance, Boost.Python can't be installed because it tries to install Graph, which tries to install GraphParallel, which tries to install Graph. The cycle between these two is an interesting one. boost/graph/breadth_first_search.hpp does: #ifdef BOOST_GRAPH_USE_MPI # include <boost/graph/distributed/breadth_first_search.hpp> #endif at its end, and boost/graph/distributed/breadth_first_search.hpp does: #ifndef BOOST_GRAPH_USE_MPI #error "Parallel BGL files should not be included unless <boost/graph/use_mpi.hpp> has been included" #endif #include <boost/graph/breadth_first_search.hpp> at its very start. So these headers include each other. One would naively think that only the parallel header should include the normal one, but one is not well versed in graph library architectures, so one might quite possibly be missing something, or a lot. Comments?

4 4

Formal Review of Proposed Boost.Histogram Library is FINISHED
by Mateusz Loskot 05 Oct '18

05 Oct '18

Dear Boost Community, The formal review of Hans Dembinski's Histogram library has been completed. Here is the quantitative summary of feedback received: * Reviews: 1. Klemens David Morgenstern 2. Jim Pivarski (off-list via e-mail to Hans) 3. Björn Reese 4. Steven Watanabe 5. Alex Hagen-Zanker * Non-review participations: 1. degski 2. Gavin Lambert 3. Seth 4. Mateusz Loskot I believe I've collected the names/numbers right, but please let me know ASAP if you think otherwise. I'd like to thank all the participants for their time and efforts. I'm sure Hans received lots of valuable comments and suggestions. FYI, the discussion threads are still open for new posts. Those won't be taken into consideration towards the review result though. I will do my best to announce the review results next week. Mateusz Review Manager for the proposed Boost.Histogram -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Twenty years and time to retire
by Beman Dawes 04 Oct '18

04 Oct '18

The idea behind Boost was hatched in March, 1998, and the proposal document <https://www.boost.org/users/proposal.pdf> was released May 6, 1998. That makes Boost twenty years old, and makes me twenty years older. It is high time I retire from Boost; I haven't been able to contribute for some time now. Thanks to all of you who made Boost such an overwhelming success in the past and will drive Boost forward into a bright future! --Beman

21 20

Release notes for release 1.69
by Paul A. Bristow 02 Oct '18

02 Oct '18

To avoid forgetting to do it when release time comes, I would like to add some Math and Multiprecision library release notes for the next release 1.69 Is providing a PR for this file that way to do this? ( I speak Quickbook ;-) ) https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… (but it doesn't exist yet!) Thanks. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

1 0

[histogram] Variance
by Bjorn Reese 02 Oct '18

02 Oct '18

The variance of individual bins can be obtained when using the adaptive_storage (via h.at(i).variance().) I am trying to understand the overhead of this feature. If I interpret the code correctly, there is a space overhead because each counter has to keep track of both the count and the sum of squares. The computational overhead is that the sum of squares has to be calculated for each insertion. Is this correct? If so, is there any way to use the adaptive storage policy without variance? Furthermore, why does variance() return the sum of squares? Should this not be divided by the sample size?

5 8

[asio] Order of asynchronous messages
by Florian Lindner 01 Oct '18

01 Oct '18

Hello, in a distributed application (only local are network) we are experiencing issues which *may* stem from the order of asychronous messages sent over sockets. We create a send buffer: auto buffer = std::make_shared<std::vector<double>>(); and fill it: buffer.push_back(some_data). This buffer is then given to our communication routine request = aSend(*buffer, recipient); to keep the send buffer alive we place it in a class attribute: bufferedRequests.emplace_back(request, buffer); The aSend method from above works like (asio is boost asio, of course) PtrRequest aSend(std::vector<double> const & itemsToSend, int recipient) { PtrRequest request(new SocketRequest); asio::async_write(*_sockets[recipient], asio::buffer(itemsToSend), [request](boost::system::error_code const &, std::size_t) { std::static_pointer_cast<SocketRequest>(request)->complete(); }); return request; } This way, we can check for completion using request->test(), which is set from the callback request->complete(). For checking of completed requests we have a loop, which is called reqularly void checkBufferedRequests(bool blocking) { do { for (auto it = bufferedRequests.begin(); it != bufferedRequests.end();) { if (it->first->test()) it = bufferedRequests.erase(it); else ++it; } if (bufferedRequests.empty()) return; if (blocking) std::this_thread::yield(); // give up our time slice, so communication way work } while (blocking); } which operates on bufferedRequests, that is a list<pair<PtrRequest, PtrBuffer>>. We use that, so that the sending peer is not blocked by a slow receiving peer. The sockets are created like tcp::acceptor acceptor(*_ioService); { tcp::endpoint endpoint(tcp::v4(), _portNumber); acceptor.open(endpoint.protocol()); acceptor.set_option(tcp::acceptor::reuse_address(_reuseAddress)); acceptor.bind(endpoint); acceptor.listen(); } Now we are having problems with mangled data that are unexplainable right now. - Is the order of requests guaranteed to be preserved? I think so, based that asio works on TCP. - What happens if there is another read or write performed on the socket. I think that there is no way to guarantee that this does not interfere with the order of the asynchronous send or queued requests. Last but not least: Do you see any potential problems with that code? Thanks a lot! Florian

3 2

[container][interprocess][intrusive][move] Removing support for old compilers
by Ion Gaztañaga 01 Oct '18

01 Oct '18

Hi, My libraries have supported quite old compilers, starting from Visual 2003 and GCC 3.4 and I'm asking for feedback before I start dropping old compilers. The number of supported plus locally+regression tested versions has increased a lot these years and that's a lot of work with reduced benefits. I run locally for: - From Mingw GCC 3.4 to GCC 8.1, all released minor versions (combining C++03-C++11-C++14-C++14). - From MSVC 7.1 to MSVC 14.1, all released versions (default language standard). I also run boost regression tests for many of those compilers (see "igaztanaga-*" runners in https://www.boost.org/development/tests/master/developer/summary.html) The number of supported and tested compilers is now unmanageable for me as many of those have specific warnings/bugs that I try to fix. So I was thinking about reducing that list a bit dropping support for the oldest ones and replacing them with recent GCC/Clang from WSL (Windows Subsystem for Linux). My first idea is to drop anything older than 10 years, which means that the minimum will be MSVC 9.0 and GCC 4.3 (both released in 2008). I've reviewed some popular long support Linux distributions: -> RHEL 6 uses GCC 4.4. -> SUSE Linux Enterprise Server 11 Service Pack 4 (SP4) uses GCC 4.3 Microsoft no longer supports Visual 2008 (support ended on April 2018) but I can continue compiling and testing it at least for another year. Note that my libraries will continue support for -std=C++03, but I will not find workarounds or fixes for old GCC and MSVC versions. Thoughts, problems, comments? Best, Ion

6 9