December 2017 - Boost - lists.preview.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

[foreach][polygon][xpressive][bimap][ptr_container][gil][assign][typeof][msm] PRs for removing executable attribute for files
by Edward Diener 08 Mar '18

08 Mar '18

The following libraries still have PRs, which I have previously submitted, for removing the executable attribute for one or more files: foreach polygon xpressive bimap ptr_container gil assign typeof msm None of these PRs affect anything other than the file attribute, so no testing is needed AFAICS since no code changes. If the maintainers of the above libraries, or someone else with write access to these libraries, can merge the appropriate PR to 'develop', and then merge 'develop' to 'master', we can get rid of having any files with their executable attribute set in the next release.

5 13

[yap] Re-announcing Yap
by Zach Laine 23 Feb '18

23 Feb '18

I posted 2-3 months ago about Yap, an expression template library I've written that I intend to propose for Boost. This is just a reminder that the library exists, and where to find it. I'm giving a talk about it at C++Now 2017, and some time after that I intend to submit it to the queue. Louis Dionne has offered to serve as review manager when the time comes. You can find the main repo on GitHub: https://github.com/tzlaine/yap And online docs are here: https://tzlaine.github.io/yap Zach

4 6

[Root Pointer] Deterministic C++ memory manager (update)
by Phil Bouchard 26 Jan '18

26 Jan '18

Greetings, I wanted to give an update to the community regarding the memory manager I wrote called: Root Pointer. I now have a working template to solve all memory leaks in C++ and C but both requires some meta data generator. The code can be found here; it is working but not polished: https://github.com/philippeb8/root_ptr In this code we can find: - node_ptr: main class of the smart pointer / memory manager. - root_ptr: generic derived class that includes an "iterator" and a pointer to the name of the instance (for debugging purposes). Also I commented some code that logs the exact location of the memory leak. Furthermore I would like to bring some observations that I found in the C and the C++ language: - Pointers and iterators are not the same; i.e. pointers should point to allocated blocks only and shouldn't have arithmetic operators while iterators shouldn't be used to deallocate anything. - C pointers can only point to dynamic arrays (size known at run-time). - C++ pointers can point to both inherited objects and static arrays (size known at compile-time). This creates a problem (see attached: array_inherited_pointer.cpp). - std::array<T> should have constructors with T objects that have no default constructor. Lastly, before I submit anything, I will have to propose a way to apply a template function to all non-static member variables of a class. This will require implicit meta data generation. This idea is not new as other libraries such as Qt is based on meta data and they certainly could make us of this. For the moment I have a parser that does the job correctly by specializing a boost::proxy() template function but eventually this will have to be integrated into the standards. Hopefully this is an important milestone! Regards, Phil Bouchard www.fornux.com

2 5

[config] Supporting newer compilers: what does it take?
by Olaf van der Spek 22 Jan '18

22 Jan '18

Hi, What does it take to support new compilers, especially MSVC? 15.6 Preview 1 has been released now. Is some documentation or policy regarding test runners etc available? https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-… Gr, -- Olaf

1 1

Informal CMake meeting at CPPCon
by Robert Ramey 12 Jan '18

12 Jan '18

Thursday 28 Sept 8 AM at CPPCon a small group of us met to talk a little regarding the situation regarding support of CMake by Boost. I promoted this meeting as I've been concerned that the only discernible results of the recent Boost Steering Committee announcement on the subject was a certain level of antagonism among boost members regarding the subject. Participants ============ Robert Ramey (me) Rene Rivera Vinnie Falco Louis Dionne David Sankel Matt Calabrese This was a small but I think a representative group. After some preliminary back and forth, I think we agreed: a) Nothing was going change regarding the current build system until there was a real alternative in place. b) That we should support serious proposals to implement CMake support within boost. c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice. d) Questions regarding the scope/implemention of such support for CMake can be handled within the formal review process. e) Other questions regarding support CMake and Boost, transition to new system, related requirements on boost libraries, etc. can be better addressed once we have some sort of consensus on the form that CMake support will take. I had contacted Paul Fultz who is the only one I know of that has proposed something specific to submit to formal review. He told me he couldn't do it at the time, but shortly there after posted such a request on the list. So I guess for now we're on our way. My motivation for posting this is to keep the boost community up to date on what's happening so that no one gets overly surprised when things start to happen. I'm not really soliciting feedback - though it wouldn't surprise me if I get some. Robert Ramey

9 18

Re: [boost] seeking endorsement for histogram library
by Bjorn Reese 09 Jan '18

09 Jan '18

I endorse boost.histogram.

6 11

[hash] Extract module from functional + std::hash_combine
by Daniel James 06 Jan '18

06 Jan '18

Hi, I'm planning to extract hash from functional into its own module, as that will apparently break the circular dependencies that functional is part of. Any objections? Also, any opinions on what the module should be called? 'hash' might suggest a more general purpose hash function, so maybe it should be called something more specific. Daniel

10 29

Interest for a Fixed Point Arithmetics library
by Julien Vernay 03 Jan '18

03 Jan '18

Hello everybody. I am working on a project that needs and can use fixed point numbers, so I started searching for a library implementing fixed point numbers, but I didn't find anything. So I was wondering if people would need fixed point arithmetics, and here I am. The aim of this FixedPointNumber is to fix the point at compile-time using template, and having another template argument for the underlying type. So we have : template<typename T, size_t N> class FixedPointNumber { T value; public: //interface }; The N last bits of value is the decimal part : so to convert a FixedPointNumber to an int, we need only to use a bitshift operator (and same for construction from int). sizeof(FixedPointNumber<T,N>) == sizeof(T) , so there is no overhead in this implementation. Arithmetic and relational operators will be implemented. Multiplication needs one int multiplication and one bit shift. Division needs one int division and one bit shift. There is only one value for zero. Sign can be extracted with Most Significant Bit. I have already a basic implementation but if it interests more people I will do a proper implementation. Thank you for reading !

4 7

[multiprecision] Help needed with strange constexpr slowdown
by John Maddock 03 Jan '18

03 Jan '18

Folks I have a very strange issue that I need help with understanding, it comes from https://github.com/boostorg/multiprecision/issues/32 but in summary: Given: #include <iostream> #include <boost/multiprecision/cpp_int.hpp> using namespace std; using namespace boost::multiprecision; int main() { __int128_t i =0; __int128_t j =0; int256_t sum =0; for (; i <1e9; i +=19, j +=13) { int256_t diff = j; sum += i * diff; } std::cout <<"Result: " << sum << std::endl; return 0; } There is a 20-30% slowdown when compiled in C++11 or later compared to C++03 with gcc 5.x or 6.x. I've tracked this down to the constexpr default constructor for int256_t (which is called inside operator* to create a temporary for the result), if I make the default constructor non-constexpr by removing BOOST_CONSTEXPR from any of: number.hpp:44 (number()) cpp_int.hpp:1077 (cpp_int_backend()) cpp_int.hpp:501 (cpp_int_base()) cpp_int.hpp: 435 (cpp_int_base::data_type()) Then the slowdown disappears. All the line numbers refer to current develop BTW. gcc-7 is better, but I notice it still generates different code if the constructor is constexpr - that greatly surprises me to be frank - is there something I'm missing about constexpr-ness that could cause this? Confused yours, John. --- This email has been checked for viruses by AVG. http://www.avg.com

3 3