- Boost - lists.preview.boost.org

Let's stop distributing binaries
by Robert Ramey 31 Aug '18

31 Aug '18

The fact is that users of boost use compilers with differing levels of C++ standard conformance. This creates a number of problems including (but probably not limited to) a) Using libraries built with different levels of C++ conformance may create ABI issues. b) it creates a discussion about "dropping C++03 support". Actually it creates a discussion about that the above actually means. c) It's motivated a suggestion that all libraries move to header only. This is not great idea - but I won't address that here. I believe all these issues - and more - would disappear if we just stopped distributing binaries. Each user would be building his own boost version with (presumably) the same compiler. Since C++03 compatible libraries are C++?? compatible, each library author can maintain the level of backward compatibility that he wishes. But if we're not going to distribute binaries, then users might as well just clone the latest "certified - good - tagged" version in the master branch from the github repo. That is, let's just stop or truncate the whole release circus. Replace with an occasional "certification/versioning procedure" which would make available a "squashed" master suitable for efficient cloning. This would make everyone's life easier. Robert Ramey

19 63

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

31 Aug '18

Sorry for all the bad line-breaks in my previous message. I don't have access to a properly configured email client right now. This should be easier to read: ====== Original Message ============== Please, let's not derail the discussion just after some consensus has emerged and just before it actually produces actionable items. Let's not make the better the enemy of the good here. I made the suggestion to commonly drop c++03 support in the hope that it would actually lead to some code simplifications and reduced coupling between the boost libraries - even if only in their implementation (if someone wanted to do a real c++14 reboot of their library, no one is/was stopping them anyway). >From the survey, I'd say interest in actually applying c++11 features in libraries that a currently supporting 03 is already relatively low, but big enough that I believe this will actually lead to some changes other than just changing the default test settings. That is with a standard almost universally supported by compilers in use today. Even though the move from 11 to 14 is much less dramatic, c++14 support is less wide spread and outside of the big three, there are many compilers where even the most recent version doesn't support c++14, so I just don't see people that are currently maintaining c++03 support in their libraries suddenly starting to use c++14. All this doesn't preclude a discussion about if and when to move to c++14 or a general policy about LTS versions and the like, but please keep it separate unless you are really, really confident it will lead to something actionable earlier than what is currently proposed. I have lots of Ideas, how boost could be reformed and/or modernized but in the end it comes down to convince the individual library maintainers to actually do something. I think the current proposal will at least spark some action. Let the announcement to move to cmake be a warning sign about realistic expectations about the evolution of boost. Maybe I'm aiming too low, but again, if you want more, please open a separate thread and most likely, whatever you come up with there will not be mutually exclusive with what is proposed here. Regarding the test settings: If c++11 is supposed to be the lowest official supported version then that is what should be tested Anything else doesn't make sense (you can't claim to support c++11 if you don't test if it actually works there). In any case, as was mentioned before, for the announcement itself we don't need give any specifics about something that is going to happen 1-1,5 years from now. How about something like " c++03 mode/compilation will no longer be tested / part off the general test/suit"? Best Mike

1 0

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

31 Aug '18

Please, let's not derail the discussion just after some consensus has emerged and just before it actually produces actionable items. Let's not make the better the enemy of the good here. I made the suggestion to commonly drop c++03 support in the hope that it would actually lead to some code simplifications and reduced coupling between the boost libraries - even if only in their implementation (if someone wanted to do a real c++14 reboot of their library, no one is/was stopping them anyway). >From the survey, Id' say interest in actually applying c++11 features in libraries that a currently supporting 03 is already relatively low, but big enough that I believe this will actually lead to some changes other than just changing the default test settings. That is with a standard almost universally supported by compilers in use today. Even though the move from 11 to 14 is much less dramatic, c++14 support is less wide spread and outside of the big three, there are many compilers where even the most recent version doesn't support c++14, so I just don't see people that are currently maintaining c++03 support in their libraries suddenly starting to use c++14. All this doesn't preclude a discussion about if and when to move to c++14 or a general policy about LTS versions and the like, but please keep it separate unless you are really, really confident it will lead to something actionable earlier than what is currently proposed. I have lots of Ideas, how boost could be reformed and/or modernized but in the end it comes down to convince the individual library maintainers to actually do something. I think the current proposal will at least spark some action. Let announcement to move to cmake be a warning sign about realistic expectations about the evolution of boost. Maybe I'm aiming too low, but again, if you want more, please open a separate thread and most likely, whatever you come up with there will not be mutually exclusive with what is proposed here. Regarding the test settings: If c++11 is supposed to be the lowest official supported version then that is what should be tested Anything else doesn't make sense (you can't claim to support c++11 if you don't test if it actually works there). In any case, as was mentioned before, for announcement itself we don't need give any specifics about something that is going to happen 1-1,5 years from now. How about something like " c++03 mode/compilation will no longer be tested / part off the general test/suit"? Best Michael

1 0

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

30 Aug '18

>From the discussion about abi compatibility when the Boost.System library is compiled e.g. in c++03 mode and then included in ac++11 project or vice versa (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_ g) > > When can we drop C++03 support? :D This will probably be ignored or shouted down, but maybe someone just needs to make a concrete suggestion about which people can discuss and vote so I'm giving it a shot: What about the first or second release in 2020 ? By then, all major toolchains have had solid c++11 support for at least 5 years ( I think, msvc was the last one with VS2015) and at least partial support for 7+ years (gcc 4.8, msvc 2013, clang 3.3). Also, most likely c++20 will be released in that year, which means that c++03 compatible libraries would have to support 5 different (and partial incompatible) language versions by then (not to mention ABI-compatibility considerations between different versions). That should also be enough time to ensure that the last c++03 release (late 2019) is really solid (for projects that still can't upgrade to c++11) and ideally there could be a few more bugfix-releases afterwards as is often done by other software projects. And before someone starts to raise straw mans: That of course wouldn't mean that a particular library *must* no longer compile in 03 mode, but one can no longer rely on the boost-internal dependencies remaining c++03 compatible. Best Mike

23 104

[ptr_container] associative container insert takes reference instead of const reference as key ?
by comic fans 30 Aug '18

30 Aug '18

Hello , I've found that ptr_unordered_map.insert has following signature (from code and latest doc) std::pair<iterator,bool> insert( key_type& k, T* x ); that forbids calls like ptr_unordered_map.insert( myobj->id(), myobj) ,I wonder if this is by design , or some other reason ? why other overload takes const key_type& k as key type? and insert always call insert_impl which have const reference as key type ? any help would be appreciated.

2 5

c++03 library survey
by Mike Dev 29 Aug '18

29 Aug '18

Hello everyone, this is closely related to the thread about "A possible date for dropping c++03 support" (https://groups.google.com/forum/#!topic/boost-developers-archive/i4UM-GfNu8w) but this is NOT meant as a vote on the suggestion, and I'd ask you to keep discussions to that thread. For the actually important part, please scroll down to the double line (===) For reference however, my suggestion was that c++03 support is officially dropped somewhere around early 2020 across all of boost. Which would mean, that from then onwards any library author could start to unconditionally use c++11 features in his library without prior announcement or transition period, even if other boost libraries that currently support c++03 have a dependency on it. (Again, if you have questions or comments about this, please answer on the other thread) Somewhat late, I realized I first should have asked if / how much actual interest there is from the side of the library maintainers in the first place, because whatever the majority of the people on the ML thinks, it obviously won't have any effect if the actually affected people don't have any interest in using c++11 in the first place. Full disclosure: I'm not a boost contributor myself (at least nothing significant) but as a user, I have an interest in boost libraries becoming simpler, less entangled with each other and providing less types that are redundant in c++11 and later. You could call that more lightweight but that is a different topic. So, to get some idea if there is any interest in this topic, I'd ask each maintainer that is currently maintaining a c++03 compatible library to answer the following questions: =======Please quote from here ====================================== - Which library/ies are you maintaining? (I assume this isn't some sort of private information - otherwise ignore the question) - Would you like to unconditionally use c++11 features if you would not have to worry about this breaking boost internal users? - Would you like to unconditionally use c++11 features if you would not have to worry about this breaking any users? - Would you deprecate your library completely if there were no boost-internal users and your current dependencies required c++11 (e.g. because your library has been merged into the c++11 standard library anyway) - Are you yourself using any boost library (in an up-to-date version) in a c++03, non-boost project? - Do you have any Idea if the latest versions of your library is used by any important/significant number of c++02 projects? [It is only important if *you* consider those projects important and or the number significant] =======Please quote till here ====================================== Note: When I'm talking about breaking users I mean breaking due to requiring c++11 compiler, not because you completely rewrite the API based on new c++11 idoms - that would probably better be done in a completely new library. Best regards and thank you for your time Mike

15 32

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

[test][pull#151] Fix warning: BOOST_CLANG is not defined, evaluates to 0
by Mateusz Loskot 26 Aug '18

26 Aug '18

Hi, I've submitted a tiny fix for this annoyance: https://github.com/boostorg/test/pull/151 May I ask the library maintainers to merge it? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 1

GNOME outreachy
by Pranam Lashkari 26 Aug '18

26 Aug '18

GSoC just finished and it helped grow the community by adding few new students and maybe mentors to our Boost community. I was hoping why don't we also apply for GNOME outreachy also it is also similar to GSoC and can also help our community to grow. and by appearing in end of year internship in GNOME outreachy we can keep a flow of new contributors and motivate people to contribute to opensource throughout the year. Thank you, Pranam Lashkari

14 26

[regex] Drawing attention to link issue
by Antony Polukhin 24 Aug '18

24 Aug '18

Hello, The build flags for shared libraries are changing right now in b2. See https://github.com/boostorg/boost/pull/190 for more info. The thing is that Boost.Regex fails to link with those new flags, probably because of the https://github.com/boostorg/regex/issues/49 issue. If there's no simple solution for the above case, then please merge the https://github.com/boostorg/regex/pull/66/ . It should help. Thanks in advance!

2 2

[MSM] Still maintained?
by Christophe Henry 24 Aug '18

24 Aug '18

>Hi Boost-list, > >because I realized that my simple PR for Boost.MSM [1] (which makes it >compilable with C++17) and an even older one did not receive any >attention, I wonder if Boost.MSM is still actively maintained. > >The latest changes seem to be from around December 2017. > >Does anyone know, if Christophe is still active? > > >Best regards, >Deniz Hi Deniz, Sorry, I didn't have time to do it before vacations, I only merged your change to develop now. Thanks, Christophe

2 1

[type_traits][core] modularisation and moving stuff about (again)
by John Maddock 23 Aug '18

23 Aug '18

So... I have a couple of PR's to move some of type_traits into config so it can be used by core. It's a modest proposal so I can go with that I guess... but this moving stuff about all over the place just to satisfy dependencies does wind me up a bit - I know that I sometime struggle to figure out where stuff is on Github - half of Integer is in Config for example. How on earth would an end user figure that out in order to file a PR or a bug report? I know... "calm down dear" and all that ;) So radical suggestion - does type_traits just belong in core and lets be done with it? What would happen to the file history if we moved it (can I still "git blame")? DARFC, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

5 16

Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
by Glen Fernandes 23 Aug '18

23 Aug '18

Andrey Semashev wrote: > I would rather encourage people use type traits, the official > interface. Boost.Config or Boost.TypeTraits could provide macros that > allow users to detect whether is_final is emulated or is the real > deal. One thing about this suggestion: If Boost.Config was to provide macros that tell users whether Boost.TypeTraits' boost::is_final<T>::value is emulated or the real deal, then the compiler detection logic currently in Boost.TypeTraits for detecting __is_final would already have to be duplicated in Boost.Config. That does not sound like a great idea. Right now TypeTraits provides both, which is better. i.e. It provides boost::is_final<T>::value and BOOST_IS_FINAL(T). The former uses the latter if it is defined, or is always false if not defined. If BOOST_IS_FINAL(T) and all its compiler detection logic lives in TypeTraits, then that all that compiler detection logic should not be duplicated in Config to provide a BOOST_HAS_IS_FINAL_INTRINSIC or similar feature detection macro. Glen

5 13

[test] I want my core dumped
by Alain Miniussi 22 Aug '18

22 Aug '18

Hi, I have assert in my library code, but when the assert fire in a test, the main function in minimal.hpp intercept the signal and explains that, yes, you asked for an abort, but no: [...] ../../../boost/test/minimal.hpp(136): exception "signal: SIGABRT (application abort requested)" caught in function: 'int main(int, char **)' Is there a way to avoid that behavior ? I need that core file. Thanks Alain

3 2

[multiprecision] Design question on variable precision types.
by John Maddock 22 Aug '18

22 Aug '18

Folks, I have a tricky design question that Boost.Multiprecision has been dodging relating to variable precision types - these have just expanded somewhat now that we support complex numbers via mpc as well as mpfr's reals etc. The basic use case is this: We have a set of numbers at very high precision, some calculations are performed on those directly, others we want to temporarily drop precision, get an approximate answer and perhaps later refine it. Generally speaking, performance trumps everything, on a really long running calculation 10-20% speedup can actually make a big difference (in $$'s in some cases if the CPU time is from the cloud). Up till now Boost.Multiprecision has been dodging this issue - it's actually pretty hard to program in a sane and consistent way, so the message has been "don't mix precisions" when using a type like boost::multiprecision::mpfr_float - just set what default you want and get on with it. But we really should do better than that. So... with the help of Danielle Brake I've been trying to nail this down in develop, what we have at present is: * Copy construction or move assignment copies the precision of the source. * Regular assignment retains the precision of the target variable. This is efficient in that assignment doesn't reallocate to a new precision, and provides an easy way to up/down sample precision when required. But it breaks equality after assignment. It does match what MPC/MPFR do in mpfr_set etc though. The fact that move assignment behaves differently from regular assignment bother me too - it's too easy to write code that triggers move semantics without noticing. The trouble is, being able to assign while retaining precision of source is sometimes useful too, so having move-assign behave differently provides a useful back door, but maybe one that's just too cute for it's own good? And then.... we get on to arithmetic. * Currently temporaries are created at current default precision. So it's easy to shoot yourself in the foot by not noticing that temporaries are being created in an expression and not having the default precision set correctly. I actually think this one might be solvable, but it's a huge job involving banning default constructors in all the backends to our number types, and then catching all the cases where they might have been used. * What should happen in "a = expression", where the variable used in "expression" are at different precision to a? The uncontroversial answer might be to adjust the result to the precision of a. But hold on... we have expression templates, and these can use variable a as working space while evaluating the expression... so the change in precision might occur *during* the computation and not after it. * Should we try to ban mixed precision arithmetic altogether? It's a tempting idea, but I can't see how to enforce it in code without also banning mixed precision assignment. Thanks for your consideration, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

[MSM] Still maintained?
by Deniz Bahadir 22 Aug '18

22 Aug '18

Hi Boost-list, because I realized that my simple PR for Boost.MSM [1] (which makes it compilable with C++17) and an even older one did not receive any attention, I wonder if Boost.MSM is still actively maintained. The latest changes seem to be from around December 2017. Does anyone know, if Christophe is still active? Best regards, Deniz [1] https://github.com/boostorg/msm/pull/15 -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Advisory Board (Chairman): Oliver Fietz Board of Management: Stephan Schröder, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

1 0