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

[filesystem] Library maintainers needed
by Beman Dawes 22 Sep '18

22 Sep '18

I'm retiring, so Boost.Filesystem needs one or more maintainers. This is a high complexity library, further complicated by (1) requiring both Windows and non-Windows implementation code and (2) needing a major upgrade for compatibility with the new standard library version shipped in C++17. Furthermore, there are constant Pull Requests and Issues that arise, and these almost invariably take a lot of time for the maintainer to process. My personal opinion is that Boost should deprecate the Boost library in favor of the standard library implementations, and do only minimal maintenance for several years until most users have migrated to C++17 or later. But that's up to the new maintainers to decide. Thanks, --Beman

3 2

[endian] Library maintainer needed
by Beman Dawes 22 Sep '18

22 Sep '18

I'm retiring, so Boost.Endian needs a maintainer. This is a low/medium complexity library that requires only minor effort to maintain. --Beman

2 1

[timer] Library maintainer needed
by Beman Dawes 22 Sep '18

22 Sep '18

I'm retiring, so Boost.Timer needs a maintainer. This is a simple low complexity library, and requires little effort to effort to maintain. --Beman

1 0

[build][testing] Tests naming in Jamfile
by Mateusz Loskot 21 Sep '18

21 Sep '18

Hi, I'm updating Jamfile-s of Boost.GIL and it made me wondering: For example: test-suite "boost-gil-test" : [ run promote_integral.cpp ] ; Apart from replacing the deprecated test-suite with alias, I wonder what is the recommended policy of naming the test suites, are there any rules? For example, should it be more or less hierarchical boost-{lib}-{testname} {lib}-{testname} {testname} or the name is completely local to/internal in a library and library maintainers are free to name as they desire? I could not find anything in the development guidelines and the testing policy docs. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net p.s. Originally posted to boost-testing incorrectly https://lists.boost.org/boost-testing/2018/09/8446.php

2 2

[system] A non-allocating message() overload
by Peter Dimov 20 Sep '18

20 Sep '18

One of the objections against <system_error> is that message() needs to allocate memory, because it returns an std::string. This is true even for user-defined categories that can implement it without allocating, with a static message table. To address this, I'm thinking of adding the following overload to boost::system::error_category (with the intent of proposing it for std::error_category): virtual char const* message( int ev, char* buffer, size_t len ) noexcept; This is modeled after the glibc-specific version of strerror_r (and in fact has the exact same signature and behavior). If the implementation has a static character literal corresponding to `ev`, it returns it directly. If not, it composes an error message into the provided buffer, then returns `buffer`. Comments?

3 7

HoF Problems with Boost 1.68 / LLVM-Clang / Windows
by Adam Hartshorne 20 Sep '18

20 Sep '18

The following two bits of code compile ok with MSVC, but using LLVM/Clang produces the following errors. Using the code in print.cpp BOOST_HOF_STATIC_FUNCTION(simple_print) = fix(first_of( BOOST_HOF_LIFT(print_with_cout), BOOST_HOF_LIFT(print_with_range), BOOST_HOF_LIFT(print_with_tuple) )); produces the following error 1>./boost_hof_functions.h(45): error : templates cannot be declared inside of a local class 1>C:\boost_1_68_0\boost/hof/lift.hpp(90): note: expanded from macro 'BOOST_HOF_LIFT' 1>C:\boost_1_68_0\boost/hof/lift.hpp(105): note: expanded from macro 'BOOST_HOF_LIFT_CLASS' And BOOST_HOF_STATIC_LAMBDA_FUNCTION(print) = boost::hof::proj(simple_print); produces >./boost_hof_functions.h(51): error : non-const lvalue reference to type 'reveal_adaptor<...>' cannot bind to a temporary of type 'reveal_adaptor<...>' 1>C:\boost_1_68_0\boost/hof/lambda.hpp(241): note: expanded from macro 'BOOST_HOF_STATIC_LAMBDA_FUNCTION'] There are nearly identical errors with functions from in.cpp.

2 1

"is-assignable" compile error using Boost 1.68 / LLVM-Clang / Windows
by Adam Hartshorne 20 Sep '18

20 Sep '18

I receive the following build error when switching to LLVM toolset in VS2017 to build code using Boost 1.68. The code builds fine with MSVC compiler. 1>C:\boost_1_68_0\boost/type_traits/has_trivial_move_assign.hpp(49): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 1>C:\boost_1_68_0\boost/type_traits/intrinsics.hpp(233): note: expanded from macro 'BOOST_HAS_TRIVIAL_MOVE_ASSIGN'

4 6

Unexpected behavior in reverse lookup (asio resolver)
by LC 19 Sep '18

19 Sep '18

When performing a reverse lookup of an address: *r->async_resolve( boost::asio::ip::tcp::resolver::endpoint_type( adr, 80 ) ...* the address itself is returned (as string), when the name of the host cannot be found. I would expect an error/exception, telling me this instead. Consider the following (custom class which does both): *Resolver::resolve< ResolverClass >( &rc, "www.yahoo.com", 1 ); Resolver::resolve< ResolverClass >( &rc, "8.8.8.8", 2 ); Resolver::resolve< ResolverClass >( &rc, "none.exist.end", 3 ); Resolver::resolve< ResolverClass >( &rc, "2.18.77.109", 4 ); Resolver::resolve< ResolverClass >( &rc, "198.252.206.16", 5 ); Resolver::resolve< ResolverClass >( &rc, "234.255.173.123", 6 );* And the result: *1: hostname: www.yahoo.com, address: 87.248.98.7, error: 1: hostname: www.yahoo.com, address: 87.248.98.8, error: 2: hostname: google-public-dns-a.google.com, address: 8.8.8.8, error: 3: hostname: , address: 0.0.0.0, error: Host not found (authoritative) 4: hostname: a2-18-77-109.deploy.static.akamaitechnologies.com, address: 2.18.77.109, error: 5: hostname: stackoverflow.com, address: 198.252.206.16, error: 6: hostname: 234.255.173.123, address: 234.255.173.123, error:* 2 is looking up of "8.8.8.8", which of course can be found and returns the google.com entry. Likewise, 4 and 5 can be found and return the correct result. *Nr. 6, however, is a non-existent ip-address. As you can see, instead of an error, the address itself is returned when calling "endpoint_iterator->host_name();".* This is unexpected and (I think) undocumented. It can be easily detected by testing if host_name returns an address, but this would require another (test) conversion; as a result you'd end up with forth&back conversions. Wouldn't it be better, if the reverse lookup returned an error/exception, if the name of the host cannot be found? This would be more consistent with the "Host not found (authoritative)" error in example 3. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 4

[cmake] Pull request announcement
by Mike Dev 18 Sep '18

18 Sep '18

Dear all, unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all). It appears that cmake efforts have yet again stalled. Last I heard was that everyone is waiting for BCM and the author of that library still tries to find a review manager. As we probably can't expect a full-fledged, boost-wide solution in the near future I'm trying it with a low-effort approach that will establish the minimal framework needed such that each library can be (where necessary) build with cmake and specify it's dependencies on other libraries (the latter being the really important part). >From that starting point a more holistic solution can then be developed step by step and (in most cases) library by library. The only fundamental thing that needs to be decided by the community is a canonical naming scheme for the cmake targets that should be used by other libraries in their `target_link_libraries` call. For that I suggest that each library should provide an alias target called Boost::<library_name> (e.g. Boost::program_options) This also follows the naming scheme provided by cmake itself when using boost libraries that are installed on the system. Now about what I'm specifically going to put into the PRs: - I'll propose a trivial, top-level cmake file be added to the boost super project that doesn't do anything but look for CMakeLists.txt files in the root folder of each library and calls that file if present - Individual libraries get a simple CMakeLists.txt file that will - create an appropriate build target - INTERFACE library for header-only - STATIC for regular libraries - create an alias named Boost::<library_name> - build the library if necessary - specifying the minimum required c++ version - specify the local include directory (iirc that will always be "include") - specify all required dependencies This will not address - Testing - Installation - Creation of shared libraries - Creation of documentation - Special provisions for IDE integration In short: all the difficult stuff is left out ;) The goal is not to present a solution that can replace b2 but to have a minimal starting point upon which individual library authors or the community as a whole can make iterative improvements. If and when BCM (or an alternative) is accepted into boost, individual libraries can then easily switch to this full-fledged solution and of course any author can create a more complete CMake solution for his library at any time (as some already have). Finally, please don't nick-pick this to death. I'd like to have a more complete solution too, but it isn't coming, so let's do the minimum we can and go on from there. Note that the advantage of such a minimal solution is also that there are very few design decisions to make that may later turn out to be wrong and then create a maintenance burden. The only things that are visible on an interface level (and thus should remain reasonable stable) are: - The alias name Boost::<library_name> - How the public dependencies are specified: target_link_libraries( boost_ foo PUBLIC Boost::config Boost::core Boost::bar ) - The position of the CMakeLists.txt file in the library root folder All of this is long established best practice. Anything else can gradually be built on top of that. Best Michael

15 38

[config] does BOOST_ATTRIBUTE_UNUSED defined implies __attribute__((used)) exists ?
by Raffi Enficiaud 17 Sep '18

17 Sep '18

Hi, I have a problem with symbol visibility in boost.test: https://github.com/boostorg/boost/pull/190 I am wondering if __attribute__((used)) is a portable way to flag a static const ref as being used, or there are variations (__attribute__((used)) vs __attribute__((__used__))). I am also wondering if __attribute__((used)) can be considered as available if BOOST_ATTRIBUTE_UNUSED is defined. Would it make sense to have an BOOST_ATTRIBUTE_USED in boost.config? Thanks, Raffi

2 1