- Boost - lists.boost.org

Re: [boost] Median in Boost.Accumulators
by Bjorn Reese 23 Sep '18

23 Sep '18

On 09/23/18 04:21, Lakshay Garg via Boost wrote: > I rolled up my custom implementation of the algorithm and > used it for my project. I wanted to check if people on > this list might be interested in such an implementation > for Boost.Accumulators in which case I can try to adapt my > implementation and send a PR. Boost.Accumulators does not seem to be actively maintained. > Performance characteristics: For a stream of n numbers, the > memory required is O(n). Median can be queried at any point > of time in O(1) and adding all the elements costs O(nlog(n)) Sounds like you keep two ordered lists (e.g. std::set) of equal size. Then the median is the first element in the second list.

2 1

Formal Review of Proposed Boost.Histogram Library is HALFWAY through
by Mateusz Loskot 22 Sep '18

22 Sep '18

Dear Boost Community, We've reach half-way through the formal review of Hans Dembinski's Histogram library. The review lasts until the end of September 26th. If you are interested in applications for mathematics, statistics graphics, image analysis, and such, or in the Histogram library itself, please consider reviewing the Histogram library by the end of September 26th. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[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