- Boost - lists.preview.boost.org

[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