- Boost - lists.boost.org

[github] Super-project not updating.
by Rene Rivera 25 Aug '17

25 Aug '17

It seems that the super-project is not getting updated for any branch since yesterday. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

[trac][poly_collection][stacktrace] request for Trac components
by Joaquin M López Muñoz 25 Aug '17

25 Aug '17

Hi, Can a "poly_collection" component (assigned to me) be added to the Trac ticketing system? I guess Vinnie'll need a "stacktrace" component, too. Thank you, Joaquín M López Muñoz

2 2

fix release for 1.65?
by Oliver Kowalke 25 Aug '17

25 Aug '17

Hello, is a fix-release for 1.65 possible? It seams that the fixes that were too late to get merged into 1.65 are need to prevent segfaults in 1.65. Oliver

3 7

[Root.Ptr] C Crash Proof - Completed
by Phil Bouchard 25 Aug '17

25 Aug '17

Greetings, Most of you know the former programming language I was working on: https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp I decided to turn this into a C parser which converts C code into C++ and adds the memory manager I wrote plus other utilities to detect the exact location the memory leaks (missing call to free()). It works with traditional missing sequential calls to free() and even references that are cyclic as you can see in the attached example (input2.c). Please note that the attached C code uses basic C++ functionality such as constructors and destructors to help having a descriptive output (input2.txt). So if you have such a memory leak problem in C then please let me know and I'll be happy to offer consulting services, remotely preferably, to the employer you're working for. The problem should be solved fairly quickly. On my side I will perhaps improve the parser if necessary and automate the whole process soon. All the best! -Phil Note: For the moment the size of arrays allocated with malloc() needs to be a compile-time constant and the returned line number is not precise.

1 0

[config] BOOST_STATIC_CONSTEXPR in C++11 vs C++14
by Lakshay Garg 23 Aug '17

23 Aug '17

This conversation is in reference to https://github.com/boostorg/math/pull/82 but I'm posting it here because it might be of interest to some. On 22 August 2017 at 13:53, jzmaddock <notifications(a)github.com> wrote: > Note that those changes don't actually make the functions constexpr - or > indeed change the way the constants are initialized - in fact in C++14 > BOOST_STATIC_CONSTEXPR doesn't even imply the constants are "const > (C++11 is different, and early implementations prevent you from writing > "constexpr const" which is what C++14 permits). Since BOOST_STATIC_CONSTEXPR behaves differently in C++11 and 14, would it be a good idea for boost.config to provide a macro for handling the `static const var = ...;` kind of variable initializations in a portable manner? Maybe something like BOOST_COMPILETIME_CONSTANT? Such a macro might will be useful for declarations where we want the variable to be a constant in all possible senses (compile-time, run-time) and allow generating the most optimal code possible with the language version, compiler being used in a portable manner. An example of the kind of constants I am talking about can be seen here: https://github.com/boostorg/math/blob/develop/include/boost/math/special_fu… Lakshay

5 8

Review Request: impl_ptr (pimpl)
by Vladimir Batov 22 Aug '17

22 Aug '17

After much procrastination I would like to request a formal review for the pimpl library... once and for all :-) (given it's been through a few almost-reviews and discussions)... to get some kind of a resolution one way or the other. :-) On one hand it is embarrassingly simple and no match to a string of late TMP submissions. On the other hand it seems quite handy for ordinary s/w folk (like me) as it formalizes, streamlines and noticeably simplifies (IMO) pimpl-based deployments and makes code-review process quite simple and straightforward. Its benefits are more visible for pimpls with exclusive-ownership proxy-implementation relationships (value-semantics pimpls) as it uses internally an incomplete-type management smart pointer instead of std:unique_ptr. Given that it is policy-based I am hoping others might get interested writing additional policies within that framework such as COW or stack-based. The major oddity/peculiarity (that caused a stir before and Gavin mentioned about a year ago) is that the main class -- impl_ptr -- is declared in the global namespace. That might happen to be a deal breaker but that's the best I could come up with to get it to work. If anyone has a better working solution, I am all ears. That "oddity" is an "implementation detail" and does not affect the user -- from the user side it appears inside boost. Like boost::impl_ptr... Internally to address that we might think of striking a compromise. For ex., instead of the traditional namespace boost { template<> class impl_ptr } have template<> class _boost_impl_ptr_ Again, that is an implementation nit, wrinkle, niggle (IMO anyway). From the outside it all looks kosher -- boost::impl_ptr<...> and such. The code and the docs are at https://github.com/yet-another-user/pimpl <https://github.com/yet-another-user/pimpl>. Due to personal circumstances Glen -- Pimpl's original manager -- had to bail out. So, if anyone kindly steps forward to manage the review, that'd be immensely appreciated. Thank you, Vladimir. P.S. Ron, I am only CCing you so that you'd put it to the schedule... Tnx.

9 28

[release] Boost 1.65.0
by Daniel James 22 Aug '17

22 Aug '17

Release 1.65.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/history/version_1_65_0.html> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.65.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Rene Rivera, Marshall Clow, Eric Niebler, Daniel James, Beman Dawes

6 5

[math] regression tests failing in develop (2017-08-21)
by Ion Gaztañaga 22 Aug '17

22 Aug '17

I'm receiving the following error in my runners: error: Unable to find file or target named error: 'polynomial_concept_check.cpp' error: referred to from project at error: '../libs/math/test' It seems related to the following change: https://github.com/boostorg/math/commit/f6495af64c05416ed098d6acf6da70911c7… Best, Ion

3 3

Broken unary_functions in numeric conversions
by Gary Furnish 22 Aug '17

22 Aug '17

SHA-1: 2009f0d4fc49a6db59b950a3140f8d1f58e1a8c6 * Revert "removed deprecated std::unary_function from various conversion functors" This reverts commit 593aafab5a7aba86f14df5f9a14a53fc4353bb00. Without this commit boost\libs\numeric\conversion\include\boost\numeric\conversion\detail\converter.hpp is broken on MSVC C++17. (See https://svn.boost.org/trac10/ticket/12972) This is still fixed in develop, does anyone know why the changes were reverted? Can we get someone to actually recommit a fix? Is numeric conversion abandoned? It doesn't look like it has been touched in over a year. Thanks

5 8

[math] mark constants as constexpr
by Lakshay Garg 21 Aug '17

21 Aug '17

Hello all The boost.math library stores quite a few constants for improving performance of various operations (example: boost/math/special_functions/detail/unchecked_factorial.hpp). I was wondering if marking these constants as constexpr would be desirable. Please provide feedback / suggestions so that I can get started :) Lakshay

2 4