November 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

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

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

[release] 1.66.0 post-beta merges
by Daniel James 19 Dec '17

19 Dec '17

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy>

14 32

[beast] Security
by Phil Endecott 13 Dec '17

13 Dec '17

Dear All, To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input. Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"? Regards, Phil.

6 10

[release] Boost 1.66.0 Beta 1 Release Candidate 1
by Daniel James 09 Dec '17

09 Dec '17

The release candidates for the 1.66.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/> The SHA256 checksums are as follows: 0e137e61069e95f61fe0e46aa4a5432e65e209e87d470ea3c15b0ea1327583ac boost_1_66_0_b1_rc1.7z eff4854c1a672830c55fd2323ebe42d5d83e0f7a3d0a9d354d8bf55289831fa0 boost_1_66_0_b1_rc1.tar.bz2 f4fb07aa1ec639707570e42a848796d9a8155f23d1ece0f0a6a0cbee99807038 boost_1_66_0_b1_rc1.tar.gz d5f480441223f45427199697edbdd78145499084f835597247a452d2a7e1e798 boost_1_66_0_b1_rc1.zip The in progress release notes are at: <http://www.boost.org/users/history/in_progress.html> And the documentation is at: <http://www.boost.org/doc/libs/1_66_0_beta1/> As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

11 42

MSVC 15.5 support
by Olaf van der Spek 05 Dec '17

05 Dec '17

Hi, 15.5 Preview has been released: https://blogs.msdn.microsoft.com/vcblog/2017/10/11/productivity-structure-v… > Unknown compiler version - please run the configure tests and report the results How do I do this? Could this message be updated to indicate it comes from Boost? Gr, -- Olaf

4 7

Announcement: Faber, a new build system based on bjam
by Stefan Seefeld 05 Dec '17

05 Dec '17

Hello, about a year ago I started to experiment with a new Python frontend for Boost.Build. After many iterations of prototyping things are starting to fall into place, and the project stabilizes. I'm thus happy to announce the release of Faber version 0.2: code: https://github.com/stefanseefeld/faber docs: https://stefanseefeld.github.io/faber While Faber retains most of the features from Boost.Build, it is redesigned from the ground up. bjam is still used as scheduling engine, but everything else is written in Python. In particular, Jamfiles are replaced by fabscripts, which are essentially Python scripts. The project contains a range of examples to demonstrate various simple use-cases, from a simple "hello world" example to demos involving autoconf-style config checks, and unit testing. I have added build logic to Boost.Python to use Faber on Travis-CI as well as AppVeyor, which also is a good litmus test for Faber's capabilities. I'd be very interested in feedback as well as contributions. Perhaps it might become possible one day to integrate Faber with other efforts to add a Python frontend to Boost.Build. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

13 48

[contract] move operations and class invariants
by Lorenzo Caminiti 01 Dec '17

01 Dec '17

Hello all, This is not really a question about Boost.Contract, but more a question on how contract programming interacts with C++ move operations. C++ requires that moved-from objects can still be destructed. Because contract programming requires class invariants to hold at destructor entry, it follows that moved-from objects must still satisfy class invariants. That sounds restrictive... and it might force the class invariants to be empty. For example, for vector a class invariant is size() <= capacity(). Should that sill hold after the vector has been moved? That means I can still call size() and capacity() on a moved-from object, which might not be the case. If some sort of moved() function could be called on a moved-from object, the invariants could be programmed as follow to work around this issue: class vector { void invariant() cont { if(!moved()) BOOST_CONTRACT_ASSERT(size() <= capacity()); ... // Only invariants that are truly needed to execute the destructor. } bool moved() const; public: vector(vector&& other) { boost::contract::check c = boost::contract::constructor(this) .postcondition([&] { BOOST_CONTRACT_ASSERT(!moved()); BOOST_CONTRACT_ASSERT(other.moved()); }) ; ... } ... }; I'm not really sure... What do you think? Do you know if this topic "C++ move & class invariants" has already been discussed somewhere? Thanks. --Lorenzo

6 11

[spirit] x3 status and docs?
by Andrey Semashev 29 Nov '17

29 Nov '17

Hi, I'm wondering what is the status of Boost.Spirit x3? Is it considered stable and ready for production use? If yes, how can I find its docs? There seem to be no mention of x3 in the docs on the Boost website.

3 2

[histogram] Working with standard algorithms
by Bjorn Reese 29 Nov '17

29 Nov '17

I would like to see a better integration between boost.histogram and standard algorithms, especially those from <numeric>. Today they do not work together because the dereference operator of the axis iterator returns a pair (index and content) rather than the content. An example of where standard algorithms could be useful is calculating the cumulative distribution of a one-dimensional histogram, which ought to be a simple as: auto& axis = h.axis(); std:partial_sum(axis.begin(), axis.end(), axis.begin()); Another example is ranking a set of histograms based on the cosine similarity [1] using std::inner_product(). [1] https://en.wikipedia.org/wiki/Cosine_similarity

2 4

[release][fusion] Permission to merge
by Kohei Takahashi 29 Nov '17

29 Nov '17

Hi release manager, I'd like to merge a PR, which fixes a regression on buggy compiler. https://github.com/boostorg/fusion/pull/162 Boost.regression shows the test was passed on develop. Regards, Kohei Takahashi

1 0

[Build] x32
by Olaf van der Spek 28 Nov '17

28 Nov '17

Hi, > libboost_system-vc141-mt-gd-x32-1_66.lib Why is this named x32? AFAIK the normal name is x86. -- Olaf

5 4

Re: [boost] Adding polymorphic_value to boost
by Phil Endecott 28 Nov '17

28 Nov '17

Peter Dimov wrote: > You can have > > vector<polymorphic_value<Shape>> v; > > and then > > v.push_back( Circle(10) ); > v.push_back( Ellipse(10, 15) ); > v.push_back( Square(11) ); Good example. Yes please. There's another way of implementing this, though; rather than pointing to the object in the heap you can store it in-place by allocating enough space for the largest possible derived subclass: class Base { ... }; class Derived: public Base { ... }; template <typename B> class polymorhpic_value_2 { B base; char enough_space_for_dervided_classes_members[1024]; public: template <typename D> // requires D is same as or derived from B void operator=(const D& d) { B::~B(this); new (this) D(d); } }; polymorphic_value_2<Base> p; Derived d; p = d; That's just a sketch; many details omitted! There are some obvious advantages and disadvantages of each approach and I'm definitely not saying this is better than the pointer-to-heap design. But I mention it for this reason: * If your proposed interface for polymorphic_value could also work for this method of implementation, then it is probably a better interface. > It's unfortunate we have to use -> instead of . but that's what's available. There have been proposals for operator. ; has this been evaluated to see how it would work with them? Similarly the unified a.b() vs. b(a) syntax proposal. Regards, Phil.

4 6

Outcome v2 peer review dates set
by Niall Douglas 28 Nov '17

28 Nov '17

Outcome v2 will be up for its post-peer-review second review between Friday 19th January and Sunday 28th January with Charley Bay once again serving as review manager. In case you'd like to give it a whirl before then: Docs: https://ned14.github.io/outcome/ Single file edition: https://github.com/ned14/outcome/raw/develop/single-header/outcome.hpp Boost edition repo: https://github.com/ned14/boost-outcome Standalone edition repo: https://github.com/ned14/outcome List of changes since v1: https://github.com/ned14/outcome#changes-since-v1 Compilers needed: GCC 6, clang 4, VS2017 (C++ 14 minimum, C++ 20 preferred) Acknowledgements ---------------- This post-peer-review complete rebuild of Outcome was actually a collaborative effort by a number of the Boost community, and it has been significantly influenced for it. I'd firstly like to thank Charley for taking on the role of review manager for a second time, especially given that he knows from the first time what an awful lot of work it's going to be for him. I am *hoping* that seeing as v2 Outcome is literally a tick box set of the changes you guys recommended last time, that this review will be a quick and simple review. We shall see. I'd like to thank Andrzej for writing the beginning of the tutorial. It set the tone and pacing which I then extended to the rest of the tutorial, and I think the benefit of that shows through as this should be a vast improvement on the (many) v1 tutorials. Andrzej also found many bugs, asked many clever "stupid questions", and acted as a constant peer reviewer throughout the development of v2, including suggesting the present design for payload transport. Andrzej has had a huge influence in the shape, and direction, of this library. I cannot thank him enough, and although he declined being listed as coauthor, I'm thinking of "special thanks to" or something like that in the authorship list as he went above and beyond in his contribution. I'd like to thank Jonathan Müller for doing so much work on his Standardese tool to support Outcome. The current reference API docs on the Outcome website are but a wisp of what will hopefully be in place by the time of the review. Jonathan has had to wrestle with many libclang demons smoked out by Outcome pushing the state of the art, and will have to wrestle with many more yet, but already the huge improvements over the doxygen reference API docs are evident. If anybody has any questions or feedback between now and the review, please let rip. Otherwise thanks for reading! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Fwd: Using 'detail' folder from a another Boost library
by Jean Guegant 27 Nov '17

27 Nov '17

Hi everyone, I am trying to unify the way Boost.Beast and Boost.Asio pick an implementation of string_view (std::experimental::string_view, std::string_view). In order to do so, I am including the header file <boost/asio/detail/string_view.hpp> within <boost/beast/core/string.hpp> (see PR: https://github.com/boostorg/ beast/pull/910/files). Is that a bad practice to include the a "detail" folder from another library? If so, what would you recommend to solve my unification problem? Sincerely, Jean

2 1

Getting started with open source
by Faisal Riyaz 26 Nov '17

26 Nov '17

Hi, I am Faisal.I am new to open source community.I am familiar with C and C++ language.I am pursuing computer engineering and presently i am in first year.I am interested in contributing to your organisation and learn some stuff. It will be very helpful for me if someone can help me get started. Faisal Riyaz

1 0

[release][build] Permission to merge
by Jürgen Hunold 22 Nov '17

22 Nov '17

Hi! I'd like to merge commit e07c805e to master. This fixes https://github.com/boostorg/build/issues/236 with my PR from https://github.com/boostorg/build/pull/263 Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

[optional] regression failures on Linux teeks
by Lorenzo Caminiti 22 Nov '17

22 Nov '17

Hello all, I see the following Boost.Option regression test failures on develop branch: http://www.boost.org/development/tests/develop/developer/optional.html === error 1 === Test output: teeks99-02-dc3.7-14-Docker-64on64 - optional - optional_test_conversions_from_U / clang-gnu-linux-3.7~c++14 Rev 05c2033df7b99d19f4939bf81ca2aeeec592993d / Fri, 03 Nov 2017 00:24:42 +0000 Compile [2017-11-03 01:39:15 UTC]: fail "clang++-3.7" -c -x c++ -Wno-c99-extensions -std=c++14 -O0 -g -fno-inline -Wall -g -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -I".." -o "/var/boost/run/results/boost/bin.v2/libs/optional/test/optional_test_conversions_from_U.test/clang-gnu-linux-3.7~c++14/debug/threadapi-pthread/optional_test_conversions_from_U.o" "../libs/optional/test/optional_test_conversions_from_U.cpp" In file included from ../libs/optional/test/optional_test_conversions_from_U.cpp:12: In file included from ../boost/optional/optional.hpp:64: ../boost/optional/detail/optional_config.hpp:152:48: error: expected value in expression # if BOOST_WORKAROUND(BOOST_GCC, >= 50000) && ^ 1 error generated. === error 2 === Test output: teeks99-02-dc5-1z-lc-Docker-64on64 - optional - optional_test_conversions_from_U / clang-gnu-linux-5.0~c++1z~lc Rev 420dd51fb237f5e75cae0aeb01ec427717e4a748 / Sat, 04 Nov 2017 15:00:43 +0000 Compile [2017-11-04 15:49:56 UTC]: fail "clang++-5.0" -c -x c++ -Wno-c99-extensions -std=c++1z -stdlib=libc++ -isystem/usr/include/libcxxabi -O0 -g -fno-inline -Wall -g -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -I".." -o "/var/boost/run/results/boost/bin.v2/libs/optional/test/optional_test_conversions_from_U.test/clang-gnu-linux-5.0~c++1z~lc/debug/threadapi-pthread/optional_test_conversions_from_U.o" "../libs/optional/test/optional_test_conversions_from_U.cpp" In file included from ../libs/optional/test/optional_test_conversions_from_U.cpp:18: In file included from ../boost/core/lightweight_test.hpp:25: In file included from /usr/include/c++/v1/iostream:38: In file included from /usr/include/c++/v1/ios:216: In file included from /usr/include/c++/v1/__locale:15: /usr/include/c++/v1/string:1942:14: error: expected ';' at end of declaration _NOEXCEPT ^ /usr/include/c++/v1/string:1947:9: error: expected unqualified-id _NOEXCEPT ^ /usr/include/c++/v1/__config:368:21: note: expanded from macro '_NOEXCEPT' # define _NOEXCEPT noexcept ^ 2 errors generated. === The first error only shows on develop, the second error shows up on both develop and master regression tests. Do you know what the issue is on this toolset/platform? I am asking because Boost.Contract uses Boost.Option so it is showing the same failures. Thank you. --Lorenzo

5 7

Re: [boost] [contract] _NOEXCEPT errors in <ostream> for Clang 5.0 C++1z on Teeks Linux
by Lorenzo Caminiti 22 Nov '17

22 Nov '17

Hello Tom, On Tue, Nov 21, 2017 at 7:16 PM, Tom Kent <lists(a)teeks99.com> wrote: > On Mon, Nov 20, 2017 at 9:06 PM, Tom Kent <lists(a)teeks99.com> wrote: >> >> I was able to get to the bottom of this, I hope the libc++ builds start >> cycling normally now. >> >> > This was marked (by me!) as a clang bug - that was fixed in clang trunk >> > in January 2013. >> > I find it hard to believe that you're running a clang built from those >> > sources. >> > >> > -- Marshall >> >> It turns out I had put in a script patch the broken ubuntu header: >> >> https://github.com/teeks99/boost-cpp-docker/blob/11e6d31ca8d28dee8bbb5536f2… >> >> This was a very brittle patch, and when ubuntu fixed it upstream (just two >> months ago!) it caused some kind of conflict. I've removed the patch from my >> teeks99/boost-cpp-docker images, so the clang-3.9, -4, -5, and -6 images >> should be able to use libc++ correctly now. >> >> Thanks for all who helped me straighten this out! >> > > There was a further issue with the need for a `-lc++abi` linker option, it > has been added and the results look better now. Yes, Boost.Contract regression tests now pass on this compiler/platform. The issue was fixed. Thanks a lot. --Lorenzo

1 0

Re: [boost] Interest for Algorithmic Adjoint Differentiation (AAD) in Boost?
by Antoine Savine 22 Nov '17

22 Nov '17

I just realized that the attachment exceeds (by far) the maximum size. With apologies (this is my first post), re-posting now without the attachment. The introduction can be found at the top level of the repository, under the name AADIntro.pdf Thank you. Antoine Savine From: Antoine Savine Sent: 22 November 2017 12:38 To: 'boost(a)lists.boost.org' <boost(a)lists.boost.org> Subject: Interest for Algorithmic Adjoint Differentiation (AAD) in Boost? AAD is a hot topic in machine learning, computational finance, and, I think, other disciplines such as meteorology. Adjoint differentiation computes a large number of derivatives sensitivities for some calculation code in constant time, and operator overloading in C++ permits its semi-automatic implementation over templated code. Please see the intro attached for details. I have been working with AAD (in finance) for 5 years. I have been developing and using professional AAD libraries, I have given dedicated talks and workshops at professional conferences such as Global Derivatives and WBS, and I have been teaching AAD at the MsC in Mathematical Finance at the Copenhagen University in Denmark (Mathematics Department). Our implementation in Danske Bank obtained in 2015 the In-House System of the Year 2015 Risk award. I am planning a book on AAD. And, although that publication is biased towards finance, I have developed an independent, simple and efficient AAD engine that can be found here: tinyUrl.com/aadCentral The implementation uses the latest developments in AAD technology for maximum performance, in particular expression templates. I thought that given the wide interest for AAD, a Boost.Aad module could make sense and I was hoping that it could be based on my developments. Please could somebody let me know if there is interest, and, if so, how I should proceed? Million thanks. Kind regards, Antoine Savine

1 0

[release][poly_collection] Permission to merge to release
by Joaquin M López Muñoz 22 Nov '17

22 Nov '17

Hello, I'm asking for permission to merge the following commit chain into release: https://github.com/boostorg/poly_collection/commit/3609895bd01e5add5971345a… https://github.com/boostorg/poly_collection/commit/18b7d88df360001c2c006f02… https://github.com/boostorg/poly_collection/commit/ce7e7aac60747c6fad5e97d2… https://github.com/boostorg/poly_collection/commit/ab32df47f8811dc7f136a166… https://github.com/boostorg/poly_collection/commit/df754527917b7be013ce558f… Fixes bring compatibility with Clang 3.3 and solve a potential UB problem related to CWG 232 and detected at http://www.boost.org/development/tests/develop/developer/Marshall-UBSAN-pol… I'm waiting for Marshall-UBSAN to cycle through these but all recently updated test runners are working fine. Clang 3.3 is already verified to work by teeks99-02-dc3.3-11-Docker-64on64. Thank you, Joaquín M López Muñoz

2 2