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

[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

Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!
by Vinnie Falco 01 Jan '18

01 Jan '18

On Sun, Oct 8, 2017 at 5:38 PM, Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> wrote: > Now, moving on... given that you have __not__ answered how your parser's > design[1] compares to the parser I've developed I'll try to provide more clarity. `beast::basic_parser` is designed with standardization in mind, as I intent to eventually propose Beast for the standard library. Therefore, I have made the interface as simple as possible, exposing only the minimum required necessary to achieve these goals which the majority of users want: * Read the header first, if desired * Feed Asio style buffer sequences into the parser * Set independent limits on the number of header and body octets * Optional fine-grained receipt of chunked body data and metadata The design of basic_parser (the use of CRTP in particular) is meant to support the case where a user implements their own Fields container, or if they want a bit more custom handling of the fields (for example, to avoid storing them). Like all design choices, tradeoffs are made. The details of parsing are exposed only to the derived class. Complexities are hidden from the public-facing interface of `basic_parser`. Implementing a stream algorithm that operates on the parser is a straightforward process: template< class SyncReadStream, class DynamicBuffer, bool isRequest, class Derived> std::size_t read(SyncReadStream& stream, DynamicBuffer& buffer, basic_parser<isRequest, Derived>& parser, error_code& ec) { parser.eager(true); if(parser.is_done()) { ec.assign(0, ec.category()); return 0; } std::size_t bytes_transferred = 0; do { bytes_transferred += read_some( stream, buffer, parser, ec); if(ec) return bytes_transferred; } while(! parser.is_done()); return bytes_transferred; } > [1] at most it hides behind a “multiple people/stakeholders agree with me” > __shield__ There's no hiding going on here. One can only measure the relative success of designs based on the feedback from users. They opened issues, and I addressed their use-cases, sometimes with a considerable amount of iteration and back-and-forth as you have seen in the GitHub issues quoted in the previous message. Now, I don't know if the sampling of users that have participated in Beast's design are representative of the entire C++ community. However, I do know one thing - if GitHub stars are any measure of the sample size of the participants, then Beast is off to a good start. Here's a graph showing the number stars over time received by boostorg/beast, tufao, and Boost.Http (the last 2 libraries having you as the author I believe): <http://www.timqian.com/star-history/#boostorg/beast&BoostGSoC14/boost.http&…> (Note that the HTTP+WebSocket version of Beast was released in May 2016). We need to be careful interpreting results like this of course so perhaps we should look at different metrics. Here are the links to the number of closed issues for Beast, tufao, and Boost.Http: 502 Closed issues in Beast: <https://github.com/boostorg/beast/issues?q=is%3Aissue+is%3Aclosed> 38 Closed issues in tufao <https://github.com/vinipsmaker/tufao/issues?q=is%3Aissue+is%3Aclosed> 13 Closed issues in Boost.HTTP, from 6 unique users not including the author <https://github.com/BoostGSoC14/boost.http/issues?q=is%3Aissue+is%3Aclosed> Again we have to be careful interpreting results like this. But it sure looks like there is a lot of user participation in Beast. If approval from a large number of stakeholders is not a compelling design motivator then what is? > This tutorial is full of “design implications” blocks where I take the time > to dissect what it means to go with each choice. Thus far, no one has asked for more fine grained access to incoming HTTP tokens in the manner of `code::method` and `code::request_target`. If this becomes something that users consistently ask for, it can be done by changing the requirements for the derived class for `basic_parser`. This way, details about HTTP parsing which most people don't care about will not leak into the beast::http:: namespace. Such a change would not affect existing stream algorithms on parsers. Thanks

5 17