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

Interest in Unicode library for Boost?
by Zach Laine 23 Sep '18

23 Sep '18

I've been working on a Unicode library for submission to Boost, with an eye toward standardizing robust Unicode support for C++. It started as a better string library for namespace "std2", with minimal Unicode support. Though "std2" may never happen, those string types are still in there, and the library has grown to also include all the Unicode features most users will ever need. You can find the Github page here: https://github.com/tzlaine/text You can find the online docs here: https://tzlaine.github.io/text If you care about portable Unicode support, or even addressing the embarrassment of being the only major production language with next to no Unicode support, please have a look and provide feedback. I gave a talk about this at C++Now in May, though it's a bit out of date, as the library was not then finished. It's three hours, so, y'know, maybe skip it. For completeness' sake: https://www.youtube.com/watch?v=944GjKxwMBo&index=7&list=PL_AKIMJc4roVSbTTf… https://www.youtube.com/watch?v=GJ2xMAqCZL8&list=PL_AKIMJc4roVSbTTfHReQTl1d… Zach

8 16

Re: [boost] Median in Boost.Accumulators
by Lakshay Garg 23 Sep '18

23 Sep '18

On Sun, 23 Sep 2018 at 12:53, Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Sun, Sep 23, 2018 at 2:45 PM Lakshay Garg <lakshayg373(a)gmail.com> wrote: >> >> On Sun, 23 Sep 2018 at 11:59, Zach Laine <whatwasthataddress(a)gmail.com> wrote: >> > Also, what if I don't actually call get() very often? >> >> If get() is not called very often, then I guess just using a plain vector and >> calling nth_element on it would be the best approach. >> >> > Is there any way to take advantage of make_heap()'s O(n) characteristics, >> > and avoid doing an O(n) push_heap() n times? I can't think of one offhand, >> > just curious. >> >> The complexity of push_heap is actually O(log(n)) and not O(n) > > [make.heap] says: > > Complexity: At most 3 * (last - first) comparisons. > Correct! complexity for make_heap is O(n) and complexity for push_heap is O(logn). https://en.cppreference.com/w/cpp/algorithm/make_heap https://en.cppreference.com/w/cpp/algorithm/push_heap

1 0

Re: [boost] Median in Boost.Accumulators
by Lakshay Garg 23 Sep '18

23 Sep '18

On Sun, 23 Sep 2018 at 11:59, Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Sun, Sep 23, 2018 at 10:59 AM Lakshay Garg <lakshayg373(a)gmail.com> wrote: >> >> On Sun, 23 Sep 2018 at 08:39, Zach Laine via Boost >> <boost(a)lists.boost.org> wrote: >> > >> > Could you compare and contrast this with the standard library's way of >> > computing a median, std::nth_element()? Yout just give it N/2 for 'n', and >> > it computes the median. >> >> The reason for not using std::nth_element was because I wanted >> to be able to query the median at any point of the sequence very >> efficiently. Had I used std::nth_element, I would have needed O(n) >> time for obtaining the median. For a case where I need to compute >> median after every single element, this would have required O(n^2) >> time for a sequence of length n. Here is my implementation in case >> you would like to have a look: >> >> https://gist.github.com/lakshayg/d27f29b4634cbfea3fc48c21b7b608ef > > I missed that the first time, thanks. > > Your implementation does not seem to support a windowed working set > (one element at a time is added and the oldest one removed). Is that right? Yes, that is correct. This approach does not support a window. > Also, what if I don't actually call get() very often? If get() is not called very often, then I guess just using a plain vector and calling nth_element on it would be the best approach. > Is there any way to take advantage of make_heap()'s O(n) characteristics, > and avoid doing an O(n) push_heap() n times? I can't think of one offhand, > just curious. The complexity of push_heap is actually O(log(n)) and not O(n)

1 0

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

[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

[system] Do you use the deprecated features or cygwin/linux/windows_error.hpp?
by Peter Dimov 17 Sep '18

17 Sep '18

I'd like to query the Boost community as to whether certain legacy features of Boost.System are in use; namely, (1) everything guarded by BOOST_SYSTEM_ENABLE_DEPRECATED and (2) the cygwin_error.hpp, linux_error.hpp, or windows_error.hpp headers. Does anyone use these, and for what purpose? I'm thinking of dropping the deprecated features. In addition, does anyone use boost::throws()? I'm thinking of at least discouraging its use in the documentation, if not deprecating it outright.

2 1

CMake and the Boost Steering Committee
by Edward Diener 16 Sep '18

16 Sep '18

I think it is a huge waste of time for anyone to discuss or implement a CMake solution for Boost until the Boost Steering Committee actually gets involves and defines what "Boost using CMake" actually means and gives the specifics as to what this actually entails. Otherwise nearly everything said about Boost and CMake, although well-intentioned, is just a lot of hot air and we are going absolutely nowhere trying to make any progress in this so-called direction. The Boost Steering Committee is largely at fault for saying that Boost would be using CMake, without defining what this actually means. Once again, as in our discussion about Boost dropping support for C++03, we are all wasting our time because the meaning of some language having been used is not clear and way too general to reach any meaningful conclusions. But in this case the only people who can really define what Boost using CMake actually means is the Boost Steering Committee, or someone representing the Boost Steering Committee on this mailing list, who can clarify what Boost using CMake is actually about, since it was the Boost Steering Committee who made the decision in the first place. If it is not the case that the Boost Steering Committee defines what Boost using CMake actually is supposed to mean but rather it is up to those on this mailing list to decide the issue, I would argue that Boost should focus on the simplest solution first, making Boost libraries, whether header-only or not, available for use in end-user CMake scripts in such a way that it will be easy to add this functionality for the 130 or so individual Boost libraries with the least amount of effort or work involved for each library, without arguing unduly about more complicated or more purist solutions. In other words lets start with the easiest, most practical solution, because I assure you when the smoke has cleared, 99% of those people involved in the discussion will not want to do the practical work of actual adding necessary CMake scripts to any of the 130 or so libraries involved, and even the maintainers of those libraries will not want to spend much time implementing some complicated CMake solution for their library. But I still think that without a specific definition of what Boost using CMake actually entails from the steering committee we are just wasting time and breath and to no good purpose.

1 0

How do I test more configurations locally
by Joshua Marshall 14 Sep '18

14 Sep '18

Hello all, How do I test more configurations on my local systems rather than relying on TravisCI and AppVeyor? I've been working on fixing up BGL to pass basic TravisCI and AppVeyor tests, but it seems I have to be particularly reliant on those online tests. I'd like to have more of that done on my local system. There is probably a way to do that, but I don't know what it is.

3 3

REMINDER: Formal Review of Histogram by Hans Dembinski
by Mateusz Loskot 14 Sep '18

14 Sep '18

Dear All, (NOTE: This is not start the review announcement yet) I'd just like to *remind* you all that the review of the Histogram library developed by Hans Dembinski is going to happen according to the schedule [1], from September 17, 2018 to Septenber 26, 2018. I will be sending the official START announcement this weekend. [1] https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[outcome] Change semantics on UB from peer review agreed semantics?
by Niall Douglas 14 Sep '18

14 Sep '18

Dear Boost, At https://github.com/ned14/outcome/issues/150, Andrzej has raised his desire to change Outcome's semantics on UB from what the two peer reviews here agreed to previously. As this would be a major change to interface different to what the consensus here agreed to, I am asking boost-dev to weigh in with its opinion. Status: ------- Outcome has been finished, apart from docs, since April (http://boost.2283326.n4.nabble.com/outcome-v2-1-progress-report-td4702900.h…) for the Boost and standalone variants, and since July for the experimental P1028 edition. The documentation has not been touched since the February review, but will be tackled when my current work contract ends this November, and I regain free time. Preamble: --------- Outcome has the notion of programmable "default actions" which occur when the user does something like call `.value()` on a `result<T, E>` which has an error. Let's call this "value-on-valueless". Outcome, as was approved here, has the following selector on `result<T, E>` in the Boost edition: ``` template <class T, class EC, class E> using default_policy = std::conditional_t< std::is_void<EC>::value && std::is_void<E>::value, terminate, std::conditional_t< trait::has_error_code_v<EC>, error_code_throw_as_system_error<T, EC, E>, std::conditional_t< trait::has_exception_ptr_v<EC> || trait::has_exception_ptr_v<E>, exception_ptr_rethrow<T, EC, E>, all_narrow >>>; template <class R, class S = boost::system::error_code, class NoValuePolicy = policy::default_policy<R, S, void>> using boost_result = basic_result<R, S, NoValuePolicy>; template <class R, class S = boost::system::error_code, class NoValuePolicy = policy::default_policy<R, S, void>> using result = boost_result<R, S, NoValuePolicy>; ``` So, if result's `E` is: - `void`, value-on-valueless calls `std::terminate()`. - contains an error code, value-on-valueless throws `system_error()`. - otherwise is hard undefined behaviour i.e. we tell the compiler that value-on-valueless will never happen, and the compiler doesn't even compile code for it to happen. The documentation, as was approved here, made it very clear that hard UB is the default for custom defined `E` types. See https://ned14.github.io/outcome/tutorial/default-actions/happens1/. A nice segfault usually emerges. For the standalone edition, judging from user feedback and bug reports, this hard UB behaviour is the most common intentional configuration for Outcome users. I have not received any complaints about this choice, if anything a majority has been choosing Outcome precisely *because* of this choice. Andrzej's request ----------------- Andrzej points out in https://github.com/ned14/outcome/issues/150 that it's too easy to get surprised by a small source change which causes the error code trait to no longer match the `E` type, thus flipping the code base from throwing `system_error` into hard UB unexpectedly and without warning. He wishes to change the default to failure to compile i.e. if result's `E` is: - `void`, value-on-valueless calls `std::terminate()`. - contains an error code, value-on-valueless throws `system_error()`. - otherwise a failure to compile with useful diagnostic. Users can, of course, manually specify a `NoValuePolicy` of `all_narrow` if they wish hard UB on value-on-valueless. It would be a non-trivial change from what peer review (twice) agreed, as the default would have substantially changed. What is boost-dev's opinion on this proposed change in semantics? Thanks, Niall

10 32

list.boost.org
by David Bellot 09 Sep '18

09 Sep '18

Hi, I'm looking for the person in charge of lists.boost.org, the mailing list server. We're having an issue on one of the mailing list (ublas). Cheers, David

3 2

[ublas] How to merge a PR?
by Frédéric 09 Sep '18

09 Sep '18

Hi, I submitted a PR 1 month ago. Something rather trivial. How can it be merge? https://github.com/boostorg/ublas/pull/56 Thanks, F

2 1

Re: [boost] list.boost.org
by Bjorn Reese 09 Sep '18

09 Sep '18

On 09/09/18 00:13, David Bellot via Boost wrote: > I'm looking for the person in charge of lists.boost.org, the mailing list > server. We're having an issue on one of the mailing list (ublas). https://lists.boost.org/Archives/boost/2017/02/232710.php

1 0

[all] Request for out of the box visibility support
by Antony Polukhin 09 Sep '18

09 Sep '18

I'd like to draw attention to a problem with Boost binaries for Linux. There's an awesome -fvisibility=hidden flag for Linux compilers that improves load times, performance, size of binaries and reduces the chance of symbol collisions. More info at https://gcc.gnu.org/wiki/Visibility . Unfortunately, most of the Boost libraries do not set it by default: - atomic - chrono - container - context - contract - coroutine - date_time - exception - fiber - filesystem - graph - graph_parallel - iostreams - locale - mpi - program_options - python - random - regex - signals - system - test - thread - timer - type_erasure - wave Moreover minority of the above libraries just do not work with the flag. Users just can not run ./b2 cxxflags="-fvisibility=hidden" because there's a chance that some library could stop linking. Actually things are even more ugly. Linux distributions usually do not tune the build flags for each package so at least Debian based distributions build Boost with default flags. Users get suboptimal builds. If you're a maintainer of one of the above libraries *please do* the following steps: * Make sure that all the public symbols are accordingly marked with appropriate BOOST_SYMBOL_* macro. Instruction is available here: https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/boo… * Turn on the visibility=hidden by default: * by adding <target-os>linux:<cxxflags>"-fvisibility=hidden" to the Jamfile if you do not care much for antique compilers (Example https://github.com/boostorg/stacktrace/blob/819f2b1c861dec7530372a990ecabab… ) * by using a more advanced technique for detecting the flag availability (For example see https://github.com/boostorg/math/blob/develop/build/Jamfile.v2#L20 or https://github.com/boostorg/log/blob/develop/build/Jamfile.v2#L24 ) P.S.: I would appreciate any comments or updates on the feature request. P.P.S.: Log, Math, Serialization (and Stacktrace) libraries already use that flag by default. Many thanks! -- Best regards, Antony Polukhin

10 33

[range] #11202: boost.sort header conflicts with boost.range header
by Steven Ross 07 Sep '18

07 Sep '18

https://svn.boost.org/trac10/ticket/11202 has been sitting for years. The "using range::sort" causing the namespace pollution needs to be deleted, and then everything depending on that inside boost needs to be fixed. This will break people dependent on the namespace pollution, but that's the only way to clean it up. Is anyone willing to take on this cleanup? Is there a good way to identify cross-library dependency breakages in situations like this so they can be fixed?

10 20