- Boost - lists.preview.boost.org

Re: [boost] A possible date for dropping c++03 support
by Glen Fernandes 29 Aug '18

29 Aug '18

Edward Diener wrote: > Other than not removing useful Boost libraries which support c++03 as > well as all subsequent C++ standard levels, and not telling people that > they can not use such libraries in c++03 mode if they actually want to > do so, I am perfectly willing to let others, including yourself, decide > the best way in which support for c++03 in Boost is reduced. My argument > has always been that putting a generalized statement on the website, > without explaining what it actually entails as far as using Boost l> ibraries is concerned, is going to lead to confusion and puzzlement > from end-users and endless questions. What can it possibly cost to > actually explain of what "Boost dropping support for c++03" actually > consists, when it is finally decided what Boost is going to do in this > area ? If it is a matter of correct grammar or exposition in the > explanation, I will gladly volunteer to write it if no one else wants to > do so. +1. It sounds like what we're going to communicate to users is that Boost library authors or maintainers are no longer required to make their libraries support C++03. Which sounds fine to me. I don't think library maintainers should be confined by users (even if the users are other Boost libraries) if they don't want to be. Any Boost library maintainers that wish to continue supporting their C++03 users will do so. Any other Boost library maintainers that depend on such libraries can drop the dependency on those libraries. Glen

3 3

Re: [boost] A possible date for dropping c++03 support
by Glen Fernandes 29 Aug '18

29 Aug '18

James King wrote: > I thought Peter Dimov got it right from the comment I saw earlier. > The project would no longer spend time and effort on qualifying or testing > C++03 compatibility. CI builds and the test matrix would no longer > specifically test C++03. The default language level for b2 builds would be C++11. Sounds right. All of these above is a much more useful statement to make to users. > Individual repository maintainers could attempt to continue to qualify > for C++03 however once an upstream dependency begins to include > C++11 code, that effort would have to give way. If an upstream dependency only works in C++11 and above, and the library maintainer wants to support C++03, they can either: A) Drop the dependency and still support C++03 B) Drop C++03 support But again it will be up to that library maintainer. > As a developer both working on and > consuming boost I would appreciate the permission to start using C++11 > without fear. You will be able to start using C++11 in the libraries that you maintain, without fear. You won't be able to force another library maintainer to let you use C++11 unconditionally in their library if they want to support C++03 users. Glen

1 0

BOOST_FOREACH on a filesystem directory_iterator?
by Peter Dimov 29 Aug '18

29 Aug '18

Boost.Filesystem apparently contains support for BOOST_FOREACH: https://github.com/boostorg/filesystem/blob/5a93351bfdf859ee47245e042973922… But it doesn't work: #include <boost/filesystem.hpp> #include <boost/foreach.hpp> namespace fs = boost::filesystem; int main() { fs::directory_iterator it; BOOST_FOREACH( fs::path const& p, it ) { } } 1>c:\boost-git\develop\boost/range/end.hpp(48) : error C2039: 'end' : is not a member of 'boost::filesystem::directory_iterator' The fix is trivial, but I wonder... how did nobody notice? Is this feature never used?

2 1

Future of the MaybeBoost Hash Library
by Ilia K 29 Aug '18

29 Aug '18

Hi! I was looking for a header-only library to compute SHA512 and found a very interesting project: The MaybeBoost Hash Library ( https://www.cs.mcgill.ca/~smcmur/hash/) that implements SHA/MD5 ect. In 2010 there was a discussion ( http://boost.2283326.n4.nabble.com/rfc-Preliminary-Hash-Library-td2668722.h…) about making it one of the Boost subprojects but nothing happened. Maybe some of you guys know what's the matter? -- - Ilia

2 1

Re: [boost] A possible date for dropping c++03 support
by Glen Fernandes 28 Aug '18

28 Aug '18

Peter Dimov wrote: > Edward Diener wrote: > > Peter Dimov wrote: > > > If I post "Boost is dropping support for C++03" f.ex. on Twitter or > > > Reddit, every single user will immediately understand what that means. > > > :-) > > > > I am not a participant of either so some of your humor is lost on me, but > > I can guess that it suggests that you do not consider the intelligence of > > the average Twitter or Reddit participant to be very high. > > No, that's not at all what I meant. I meant what I said. Users will > immediately understand "Boost is dropping support for C++03". I doubt hat. After the "Boost is moving to CMake" announcement on Reddit, I have a different interpretation of what Reddit will understand from "Boost <anything>". We should do things first, then announce that we've done them. Glen

2 1

1.68 Getting Started links to 1.67
by Olaf van der Spek 28 Aug '18

28 Aug '18

Hi, > The most reliable way to get a copy of Boost is to download boost_1_67_0.7z or boost_1_67_0.zip and unpack it to install a complete Boost distribution.1 1.67? Actually the best way is to use vcpkg if possible (IMO). https://www.boost.org/doc/libs/1_68_0/more/getting_started/windows.html -- Olaf

6 18

Add an adapter to cover fast bit functions
by Evgeny Shulgin 28 Aug '18

28 Aug '18

Hi all, some days ago I opened a thread about DynamicBitset[1] (where I noted that a small piece of code may double the speed of a function), which received some interesting answers (you guys rock!) I looked deeper and realized that Boost doesn't have functionality to do common bit operations *really* fast. Let me explain - there are several places in Boost where we needed to solve typical tasks connected with bits in integers - like "get log2 of an integer rounded down" or "get the number of trailing zeros" or "count number of 1-bits", and Boost contributors have been inventing there a wheel everywhere, with varying degrees of optimality: [2] - [6]. Moreover, if a programmer writes a cross-platform app and has to do smth with this stuff, it's likely that for bit operations he will write a "naive" implementations - e.g. getting the log2(x) for O(log N), when it could be done for O(log log N), but with a more complicated code. Also, as well as "smart" algos, there are other methods to use - precalced tables, taking a small additional memory when needed [6], and intrinsics (that are CPU-specific). Combining of these methods (intrinsics when conveniently, or tables/algos) gives a notable shift in performance - here's my benchmark [7] from my tiny library [8]. Performance here varies from *9.2%* to *36.9%* of speed of related naive functions. I can tell you a usercase - as a hobby I'm writing a chess variants engine (where bitsets used to represent chess board, and its size is *not* fixed to 64), and bit operations' speed there is a matter of life and death. So, what do you think of an adapter header in Boost, covering all these operation of all integer types (and maybe some other one-liners like `is_bit_set(x, pos)` ), which keeps programmers out of platform specifics? It may look as smth like this [8] (I wrote only 3 functions, but it's enough to show the potential). I guess it can be placed somewhere to *Boost.Algorithm*, and supported with CI build tests of different platforms. P.S. The (incomplete) list of bit functions, that will give a *notable* better performance compared with naive algos and even some "smart" (because of precalc/intrinsics): - count of bits - parity of bit count - first 1-bit - last 1-bit (aka integer_log2(x)) - leading zeros - trailing zeros - swap(x) - returns x with the order of the bytes reversed; for example, 0xaabb becomes 0xbbaa. (bytes here are 8 bits exactly) - rotate_left(x, shift) - rotate_right(x, shift) Other functions may look like `is_set(x, pos) -> return x & (1 << pos)` and aren't so interesting. [1]: https://lists.boost.org/Archives/boost/2018/08/242825.php [2]: https://github.com/boostorg/integer/blob/develop/include/boost/integer/inte… [3]: https://github.com/boostorg/move/blob/develop/include/boost/move/algo/detai… [4]: https://github.com/boostorg/dynamic_bitset/blob/develop/include/boost/pendi… [5]: https://github.com/boostorg/integer/blob/develop/include/boost/integer/comm… (really almost the whole file) [6]: https://github.com/boostorg/dynamic_bitset/blob/develop/include/boost/detai… [7]: https://gist.githubusercontent.com/Izaron/8c94b76818393ffd93613d255033bb48/… [8]: https://github.com/Izaron/bit_algo/blob/master/include/bits.hpp

5 6

A possible date for dropping c++03 support
by Mike Dev 28 Aug '18

28 Aug '18

> -----Original Message----- > From: Glen Fernandes <glen.fernandes(a)gmail.com> > Sent: Tuesday, August 28, 2018 1:25 AM > To: mike.dev(a)gmx.de > Subject: Re: [boost] A possible date for dropping c++03 support > > On Mon, Aug 27, 2018 at 1:10 PM Mike Dev <mike.dev(a)gmx.de> wrote: > > Conditionally using a c++11/14/17 feature is (usually) not the problem > > although there are sometimes pitfalls as Peter mentioned. However, it also > > has limited utility. E.g. it doesn't make sense to simplify a function > > implementation using c++11 features like auto, range based for, decltype, > > constexpr instead of TMP, if you have to maintain the c++03 code path as well. > > In principle, you could conditionally get rid of some boost dependencies > > in c++11 mode, but again at the cost of maintaining two different code > > paths (as boost types often have slightly different semantics from c++11). > > So why do it? And you still can't deprecate the dependency itself because > > it is still needed in c++03 mode. > > Why do it? I do it when it provides some benefit to the users: > > e.g. If alternative implementation using C++14 constexpr results in > faster compilation for users. > If supporting C++11 move semantics results in better performance > for the users. > If supporting C++11 variadic templates results in a more > flexible interface for the users. > > i.e. If I'm the maintainer, and I'm happy to have that burden of > maintenance, why does anyone else care that I support > C++03/C++11/C++14 users, in addition to C++17 users? > > Yes, these are the high value proposition cases, that you mention. > > There's also no dependency to the user is there?. e.g. If a library > obtain std::addressof from <memory> in C++11 mode and doesn't source > it from Boost.Core, to the user, the library doesn't depend on > Boost.Core. > > > So except for cases with a very high value proposition (move semantics, > > simplified api, c++11 only functionality) or simple annotations (noexcept, > > override) using c++11 features *conditionally* is usually not all that > > beneficial. My hope here is that at some point, those boost libraries > > will finally start to use c++11 features *unconditionally* in order to > > simplify things - not add even more complexity in the form of conditional > > compilation. > > Simplify things for which party? Are you worried about users or Boost > library authors/maintainers? I don't see how users are inconvenienced > unless the user wants some feature only available in later C++ modes > that the library maintainer refuses to implement. > > Glen There are (at least) three problems: 1) Not all dependencies are private. If a library e.g. uses boost::function in its interface (in particular if it returns one) the user is also directly affected by changes to that dependency. 2) As you know, the c++ compilation model is incredibly leaky, meaning transitive dependencies are not hidden from the user. E.g. if you are using boost core in your header and I include it, I do get all the symbols (including macros) in my TU too. Boost has (usually) very good hygiene, so the main problems here are usually compilation times, sometimes code size and tools (code highlighting, static analysis, refactoring etc.) that either get slower or totally break e.g. because they don't have a perfect emulation of the compilation environment and don't know which code paths are the currently active ones or are just not able to understand all the TMP. 3) Not every library in boost is as well maintained as yours and I as a user prefer "cleaner / simpler" libraries because they a) tend to have fewer bugs, b) I can more easily modify things myself if necessary, c) the easier the life of the maintainer, the more likely he has time to add new functionalities. Finally, if boost can deprecate and at some point even remove some libraries, then their maintainers (in particular the CMT) can focus their time on different projects. Btw.: In case this was not clear: I'm not a boost contributor myself and for some time now, we (as in our company) are actively trying to avoid boost dependencies for various reasons that have more to do with boost-internal stuff and the boost eco system than with e.g. inconvenient interfaces. So yes, at least some end-users do really care about the internals of boost. But admittedly, I mostly work on (semi-) embedded projects where we have to compile (and on rare occasion even modify) boost ourselves - not sure how common that is. Best Mike

3 3

[gil] Template instantiation with GCC 8 is 50x slower than with clang++
by Mateusz Loskot 26 Aug '18

26 Aug '18

Hi, One of Boost.GIL users reported very long compilation times with GCC 7 and 8 https://github.com/boostorg/gil/issues/131 then, reproduced the problem with a minimal example without Boost GIL and MPL dependencies. The issue has been reported to GCC developers - I think users/developers of other Boost libraries may be interested too https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87107 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[dynamic_bitset] Using of GCC built-in functions may increase performance of some methods
by Evgeny Shulgin 26 Aug '18

26 Aug '18

Hi all, when I was playing around the Boost.DynamicBitset library, I noticed the last lines of the count() function (which returns the number of bits in the bitset that are set): return do_count(m_bits.begin(), num_blocks(), Block(0), static_cast<value_to_type<(bool)mode> *>(0)); Well, this line was modified 10 years ago last time. Let's go deeper. GNU C provides several language features not found in ISO standard C. These include a bunch of bit operations - you can look at them here: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html. For example, *__builtin_popcountll *counts the number of bits in an 'unsigned long long', so we can use this kind of code to calculate bits (don't judge, I wrote this fast and didn't think of coding standards): size_type res = 0; for (size_type i = 0; i < m_bits.size(); i++) { res += __builtin_popcountll(m_bits[i]); } I checked that m_bits[] and popcount() both work with 64-bit values on my machine. It halved the running time of a program that has a bitset and calls count() over and over again - here's the code <https://gist.github.com/Izaron/5005fed4184ee6483699191dc5ef3677> I used. These __builtin_XXX functions can be used everywhere where it's possible, with preprocessor directives. Or is it actually used and longer time means something else? I used the latest version of Boost.

6 8