- Boost - lists.boost.org

[windows] Wni32/Vigorf.A trojan in boost_1_67_0-msvc-14.1-64.exe?
by Mateusz Loskot 28 May '18

28 May '18

Hi, One user reported via #boost at cpplang.slack.com that Windows Defender reported trojan in the latest Windows binaries. I checked myself and I can confirm the latest up-to-date Windows Defender is detecting Vigorf.A in the installer archive. Is this false report? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 7

Boost.DisjointSets and Boost.Container
by James E. King, III 27 May '18

27 May '18

Currently the disjoint_sets repository ( https://github.com/boostorg/disjoint_sets) holds a single class in "boost/pending" that is only used by the graph and graph_parallel projects (that I can tell...). I'd like us to consider taking disjoint_sets out of pending state and make it official as part of Boost Containers. Both Graph and GraphParallel require linking already, and they may already use Boost.Containers (I haven't checked). disjoint_sets is header-only however and this might cause problems for anyone relying on it, however since it's in boost/pending, I wonder if anyone is actually using it. Given the pending designation on it however, a breaking change seems reasonable to me. It will reduce the burden on the CMT, and container has at least some CI on it already. Thoughts? - Jim

1 0

[SPAM]
by Scott Karns 25 May '18

25 May '18

http://follow.anthologypaper.com Scott Karns

1 0

Interest in a tiny kmeans library
by Raffi Enficiaud 23 May '18

23 May '18

Dear all, We are finishing the cleanup of a tiny kmeans library. For those who do not know, kmeans is a widely used data clustering algorithm. This special implementation has a lower runtime complexity by taking advantages of the triangle inequalities between clusters and data points at each iteration. This implementation is based on the paper of Charles Elkan https://www.aaai.org/Papers/ICML/2003/ICML03-022.pdf We have also python and matlab bindings, fully generic on the data type, and with additional initialization heuristics. I would be happy if we can release this library into Boost. Do you think there is any interest for the community? Best regards, Jean-Claude Passy and Raffi Enficiaud

5 5

PR: Remove safe_bool idiom from boost.tribool
by Robert Ramey 22 May '18

22 May '18

Removed usage of "safe_bool" idiom from tribool. This was initially motivated by the fact that usage of this idiom with all current and past gcc compilers with constexpr does not work. First it reports reference to the address of a local member function as not being constexpr. This may or may not be correct according to the standard. FWIW clang is OK with it. Making the member function constexpr fixes this error. But still there is a problem. in GCC, the operator to implicitly covert the instance to a void * does not seem to work. Invocation of this operator in the context of an argument to an if(... or other conditional doesn't result in behavior similar to bool. Not even a static cast to a bool seems to work. Again CLANG is OK with all this. This has been reported as an issue to the GCC team. One idea which has been tried is to use C++11 "explicit" as a substitute from the safe_bool idiom. Unfortunately this breaks legacy code. bool f(x) { return tribool(true); // fails } So this is not a great solution either. Attempts to resolve this were inconclusive. This motivated me to think about why the safe_bool idiom was being used here at all. According to articles on safe_bool articles this main reason is to support the common practice of using a not null value in a conditional: Testable t; if(t) ... without accidentally permitting things like if(t >> 1)... The above would occur if Testable included an operator bool () const member function. Basically safe_bool is meant to support the common C/C++ practice of implicity converting something to bool so we write something like if(t) ... to mean t "is_valid" or "is_not_null" or some such. a) I don't think this idiom is a good idea and even more so in the context of modern C++. Conversion of a Testable instance to a bool instance should result in something that looks/acts like a C bool - not something else like a void * which C then maps to a bool. If we want to use a bool for something like "is_valid" we'd be much better off just implementing is_valid directly. There would be then no confusion, side effects or hand a waving. b) it's an especially a bad idea for tribool. The motivating concept behind tribool is that of some sort of "extended" bool. The naming suggests that it acts like a bool. But since we've used he safe_bool idiom, it doesn't any more. That is we can't use a tribool anywhere a bool is used. So if we use operator bool we'll get a tribool which acts like a bool - even when the original usage of bool was a bad idea according to a) above. But at least we have the same behavior for tribool and bool which is a lot more intuitive and less confusing. Also, changing to operator bool () will address the current problem with GCC not supporting a constexpr version of tribool. Accordingly, I've submitted this PR to change the implementation of tribool to avoid the safe_bool idiom.

7 22

FWD: [cfe-users] Boost.GIL test failing with clang 5.x while pass with 15 gcc/clang versions
by Mateusz Loskot 21 May '18

21 May '18

Hi, I posted this to clang mailing list a http://lists.llvm.org/pipermail/cfe-users/2018-May/001335.html but since it is related to Boost.GIL bugs I'm investigating, I'd like to reach for feedback here too. I'll appreciate any comments regarding the issue explained below. ML ---------- Forwarded message ---------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: 19 May 2018 at 21:38 Subject: Boost.GIL test failing with clang 5.x while pass with 15 gcc/clang versions To: cfe-users(a)lists.llvm.org Hi, While testing Boost.GIL library [1] with gcc and clang, I noticed a peculiar issue. One particular test is failing with lang 5.x while passing with total of 15-17 other versions of clang and GCC (total workflow of CircleCI with at [2]). Below is extracted minimal program equivalent to Boost.GIL channel_invert algorithm. It includes two variants: plain expression and the same expression wrapped with a function template: #include <limits> #include <iostream> #include <typeinfo> template <typename C> inline C channel_invert1(C x) { return std::numeric_limits<C>::max() - x + std::numeric_limits<C>::min(); } template <typename C> inline C channel_invert2(C x) { return (x - std::numeric_limits<C>::max()) * (-1) + std::numeric_limits<C>::min(); } int main() { int x = std::numeric_limits<int>::min(); std::cout << x << std::endl; // plain expressions int x_invert1 = std::numeric_limits<int>::max() - x + std::numeric_limits<int>::min(); int x_invert2 = (x - std::numeric_limits<int>::max()) * (-1) + std::numeric_limits<int>::min(); std::cout << x_invert1 << std::endl; std::cout << x_invert2 << std::endl; // the same expressions wrapped in function template std::cout << channel_invert1<int>(x) << std::endl; std::cout << channel_invert2<int>(x) << std::endl; } If compiled as optimised variant (-O2 or -O3) with clang 5.x outputs the following: -2147483648 2147483647 2147483647 -1 -1 The last two negative one is not expected. If compiled with clang 3.9, 4.0 or gcc from 5.1 to 7.3 it outputs -2147483648 2147483647 2147483647 2147483647 2147483647 Could anyone help me to understand what is going on in the clang 5 case? Or, what UB is this hitting? [1] https://github.com/boostorg/gil/issues/89 [2] https://circleci.com/workflow-run/3a14dd64-6c38-46b2-a6da-678c0075ca27 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Enabling issues on boostorg/mpi
by Alain Miniussi 21 May '18

21 May '18

Hi, Could somebody with the sufficient permissions enable issues on the github mpi repository ? Thanks Alain Miniussi

2 2

Proposal for a thread synchronisation primitive: future_queue
by Martin Hierholzer 21 May '18

21 May '18

Dear boost developers, I want to propose a thread synchronisation primitive, which works like a mixture of (lockfree) queues and futures. Therefore I gave it the name "future_queue". It is basically a lockfree queue which can be waited on for new values (without busy waiting), but it has some nice extra features like when_any() and continuations. The github project can be found here: https://github.com/mhier/future_queue It already contains a README file with a short description, an example and results of a first performance measurement. Further documentation so far exists only inside the code: https://github.com/mhier/future_queue/blob/master/include/future_queue.hpp My first question is, whether this is really something new (I might have overlooked something in the many boost libraries) and if it makes sense to integrate it into the boost libraries. Another question would be whether this should really be its own library, since it is basically a single class (with a few helper classes) and a single non-member function. Maybe it would be better to make it part of an existing library? I am happy to receive some first feedback! Cheers, Martin -- Martin Hierholzer DESY Notkestrasse 85 22607 Hamburg Office 55a / 123 Tel: +49 40 8998 1897 Mob: +49 176 992 46 476 Skype: mhier48 This e-mail may contain confidential and/or privileged information and is intended only for the use of the individual or entity named above. If you received it in error, please advise the sender immediately by reply e-mail and delete the original. Any further use - especially any form of publication - of this e-mail without explicit authorisation is strictly prohibited.

4 11

[Hana] "basic_tuple.hpp" bug when building with VS2017
by Daniel Chen 20 May '18

20 May '18

Hello, Just installed Boost and Visual Studio 2017 a few days ago. Here is a bug when building with Hana's "basic_tuple.hpp" header with Visual Studio 2017: In basic_tuple.hpp: template <> struct drop_front_impl<basic_tuple_tag> { template <std::size_t N, typename Xs, std::size_t ...i> static constexpr auto drop_front_helper(Xs&& xs, std::index_sequence<i...>) { return hana::make_basic_tuple( detail::ebo_get<detail::bti<i+N>>(static_cast<Xs&&>(xs))... ); } template <typename Xs, typename N> static constexpr auto apply(Xs&& xs, N const&) { constexpr std::size_t len = detail::decay<Xs>::type::size_; return drop_front_helper<N::value>(static_cast<Xs&&>(xs), std::make_index_sequence< N::value < len ? len - N::value : 0 >{}); //<Bug here - line 197 of basic_tuple.hpp } }; Upon building with "basic_tuple.hpp", the line highlighted in green reports an error: "syntax error: unexpected token ')', expected 'id-expression'". Focus on the line above that one: N::value < len ? len - N::value : 0 If you add parentheses, the error goes away: (N::value < len) ? len - N::value : 0 A similar bug occurs - and is fixed likewise - in the "string.hpp" header file at line 275, that is: template <> struct drop_front_impl<string_tag> { ... template <char ...xs, typename N> static constexpr auto apply(string<xs...> const& s, N const&) { return helper<N::value>(s, std::make_index_sequence< N::value < sizeof...(xs) ? sizeof...(xs) - N::value : 0 >{}); //<bug here - line 275 of string.hpp } I'm not sure if this is a Microsoft compiler issue (I will post to them as well), but I feel like someone should add those parentheses (and then some) to the line since it is safer - the "<" can be easily confused for a template bracket instead of a less-than sign by a parser. Daniel Chen Infinera

2 1

Boost.Test, cygwin, and ISO/POSIX
by James E. King, III 19 May '18

19 May '18

Hello, I have been adding some CI infrastructure to the CMT repositories and found I am able to reproduce a failure building boost libraries that use Boost.Test for their unit tests. If you build with "cxxstd=03" you can get to some undefined functions. See: https://github.com/boostorg/test/issues/144 It looks like one needs to define _POSIX_C_SOURCE=200112L or cxxstd-dialect=gnu in order for these functions to become visible. I was thinking of addressing this two ways: 1. I want to change boost build (bjam) to define _POSIX_C_SOURCE when building on cygwin to this value if it is not otherwise defined. I can't find the right place to add this. 2. I don't think it's reasonable for Boost.Test to modify _POSIX_C_SOURCE since it could be included after sys/functional header, so I would like to either change Boost.Test so it does not depend on these three functions, or check to see if the right preprocessor definitions are set on cygwin and put up a better error message, or simply change the documentation and update all the CI build scripts in all the affected repositories to set _POSIX_C_SOURCE as part of the CI build. Any thoughts or other ideas on this? Thanks, Jim

1 0