- Boost - lists.preview.boost.org

[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