- Boost - lists.preview.boost.org

gil: extension/numeric missing in tarball(s)
by Tim Blechmann 14 Apr '17

14 Apr '17

hi all, the complete folder with the gil numeric extensions is not included in the tarball ... is this a bug or a feature? https://github.com/boostorg/gil/tree/develop/include/boost/gil/extension/nu… thnx, tim

4 6

[release 1.64] - BOOST_NO_CXX17_STD_APPLY missing in documentation
by Oliver Kowalke 14 Apr '17

14 Apr '17

I checkted the documentation of boost-1.64 beta2 and it seams that the documentation lost the description of BOOST_NO_CXX17_STD_APPLY. May I provide a patch that gets merged into the 1.64 release? Oliver

3 3

[config] defect macro for chrono literals
by Oliver Kowalke 14 Apr '17

14 Apr '17

boost.config defines BOOST_NO_CXX11_USER_DEFINED_LITERALS but I believe this defect macro could not be used for detecting chrono literals support. Should the new BOOST_NO_CXX14_CHRONO_LITERALS depend on the compiler or stdlib version? AFAIK chrono literals are available since gcc-4.9.3 (clang?, intel?, msvc?). Oliver

2 2

[CallableTraits] Closing the review period
by Louis Dionne 12 Apr '17

12 Apr '17

Dear Boost, The review period for CallableTraits is about to conclude (in about one hour, PST). So far, I have counted 5 formal reviews, alongside with other valuable feedback. All 5 formal reviews recommend acceptance (along with improvement suggestions, but I read none of them as being conditional). I will weight the different comments received through formal and informal reviews and come back with a decision regarding CallableTrait's inclusion in Boost by the end of next week. Thanks for everyone's involvement in the review. Louis P.S.: If you have a late review, submit it ASAP and I will consider it!

1 0

[release] 1.64.0 closed for all changes.
by Rene Rivera 12 Apr '17

12 Apr '17

The Boost 1.64.0 master branch is now closed for all changes. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[CallableTraits] The formal review begins today
by Louis Dionne 12 Apr '17

12 Apr '17

Dear Boost community, The formal review of Barrett Adair's CallableTraits library begins today, April 3rd, and ends on April 12th. CallableTraits is a C++11 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal P0172, and removes the need for template specializations for different function signatures. You can find the documentation of the library here: http://badair.github.io/callable_traits/doc/html/index.html and the GitHub repository here: https://github.com/badair/callable_traits We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost, and conditions for acceptance if any - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? We await your feedback! Regards, Louis

12 28

Formale Review: Callable Traits
by Peter Dimov 12 Apr '17

12 Apr '17

I think that the Callable Traits library should be ACCEPTED. The design of the library is sound, although I'm not fond of the ad-hoc metaprogramming part in "parameter list features". This is no fault of the author though, as without a modern type-metaprogramming library in Boost, everyone has to solve this problem in some way. Still, I think that most of these should be removed. Getting the arguments as a tuple that includes the class type as a first parameter raises the obvious question of void(foo::*)(float, char, int) -> tuple<foo&, float, char, int> void(foo::*)(float, char, int) & -> tuple<foo&, float, char, int> I understand why that is, but it still makes args lossy and the original can't be recreated from the tuple. Trailing varargs also have the same problem, as (float) and (float, ...) map to the same tuple. The obvious theoretically consistent approach here is void(foo::*)(float, char, int) -> tuple<foo, float, char, int> and void(float, ...) -> tuple<float, ct::varargs_t> which would be fully reversible but could possibly be less convenient in practice. I've a feeling that it might also be useful to provide an extractor that, for member pointers, returns just the arguments without the class. In "member qualifier features", I'm missing remove_member_cv_ref (obvious semantics) and copy_member_cv_ref (copies cv+ref from one member pointer to another.) In "member pointer features" we have the same problem in qualified_parent_class_of as in args, void(foo::*)() -> foo& void(foo::*)() & -> foo& It makes more sense for the first to yield 'foo', although this again may make the trait less convenient in practice. It would also _probably_ make sense to provide apply_qualified_member_pointer, which, given void(float) and foo const&, would yield void (foo::*)(float) const&. I did not look at the implementation. I ran the test suite on Windows under Cygwin g++ 5 in 11/14/1z, Cygwin clang 3.9 11/14/1z, msvc-14.0, msvc-14.1. The tests passed. Took a look at the tests themselves, the coverage looks excellent. The reference documentation is very good, although as already noted, it uses the terms of art "implementation defined" and "undefined behavior" incorrectly, this must be fixed. The non-reference portion is a bit thin. It would be improved considerably by presenting a few real-world use cases. All in all, a solid library that solves a real problem, even though the problem remains somewhat of a mystery for the uninitiated. :-)

4 4

Libraries and C++ compliance
by Edward Diener 12 Apr '17

12 Apr '17

I would like to ask people who present new libraries to Boost, in whatever stages they are, to please specify in the documentation to the library and/or in messages regarding the library, what level of C++ compliance is needed to use the functionality of that library. This plea is not being directed at any particular current library being mentioned by anyone on the mailing list, but is a general plea regarding developers and their efforts. I realize it is a real pain that C++ as a language, and as it continues to evolve, has a number of popular levels of C++ compliance. This is largely because C++ is offered by a number of different vendors in a number of different supported releases, each particular implementation supporting a number of levels of C++ compliance and sometimes only partially supporting a particular level of C++ compliance. But given this sometimes difficult situation I do not see it as enough for library docs/information to simply say "this library supports some-vendor/some-release" because this is actually fairly meaningless to me when I know that "some-vendor/some-release" supports a number of levels of C++ compliance through some compiler parameter ( often -std=something ). Therefore docs/information of "the library supports "some-implementation" or "the library is compliant with "more than one level of C++ compliance" tells me as much as if some one told me that the moon is yellow. So I am begging, pleading, entreating library authors to be specific about the C++ features or the C++ level of compliance needed to use their library, even if it is just a one-liner that succinctly explains what the end-user needs to know. Furthermore, for any given library could we please have specific information about what will happen if I use the library, or some feature of the library, without the desired minimum level of C++ compliance. While I would assume compile-time compiler errors as the norm another possibility, especially given the excellent support in Boost Config to compiler conformance, are more readable preprocessor errors. Finally a library might offer some level of advanced C++ compliance but fall back to a lower level if possible. Please, please library authors this is important. No end-user or tester of your library wants to spend extended time trying to figure out why some compile fails when the answer turns out simply to be one of inadequate C++ conformance level for a particular compiler implementation being used with a particular level of conformance.

13 29

Re: [boost] [proposed][histogram]
by Bjorn Reese 12 Apr '17

12 Apr '17

On 04/12/2017 11:37 AM, Hans Dembinski via Boost wrote: > The library implements a histogram class (a highly configurable policy-based template) for C++ and Python in C++11 code. Histograms are a standard tool to explore Big Data. They allow one to visualise and analyse distributions of random variables. A histogram provides a lossy compression of input data. GBytes of input can be put in a compact form which requires only a small fraction of the original memory. This makes histograms convenient for interactive data analysis and further processing. Given that the compression is lossy, I am wondering how it compares with a distribution estimator like: https://arxiv.org/abs/1507.05073v2 A common use-case when collecting numerical data is to determine the quantiles. Boost.Accumulators contains an estimator (extended_p_square) for that. The advantage of such estimators are that they execute in constant time and with constant memory usage, where the constant depends only on the required precision. PS: I am aware that this is a non-trivial question, so I do not expect an answer.

3 4

[proposed][histogram]
by Hans Dembinski 12 Apr '17

12 Apr '17

Dear Boost community, after another year of work, I hope to raise your interest once again in a much improved version of "histogram", a library proposed for inclusion in Boost. https://github.com/HDembinski/histogram http://blincubator.com/bi_library/histogram-2/?gform_post_id=1582 The library can be build either with b2 or cmake. It compiles successfully with several versions of clang and gcc and has 99 % test coverage (the remaining 1 % are basically un-hittable branches). Boost-style documentation is available. The library implements a histogram class (a highly configurable policy-based template) for C++ and Python in C++11 code. Histograms are a standard tool to explore Big Data. They allow one to visualise and analyse distributions of random variables. A histogram provides a lossy compression of input data. GBytes of input can be put in a compact form which requires only a small fraction of the original memory. This makes histograms convenient for interactive data analysis and further processing. A histogram implements a quantisation of a space of input values. The space is divided into non-overlapping cells. Instead of remembering the exact values of a tuple in that space, one just increases a counter in the corresponding cell. This is the lossy compression, you only remember the count in the cell and not the original values. There are subtleties related to the counting if you want it to be safe and efficient. The library handles this for you. The standard policy implements intelligent counters which are fast, conserve memory, and are guaranteed to not overflow or get capped (capping happens when you use floating point numbers to count, like some implementations do). This is one of the two main feature of the library. The other main feature is that the library allows you to seamlessly create one or multi-dimensional histograms using various schemes to divide the input space. A so-called axis class handles the division into cells along each dimension. There are several ways how you might want to define the cells that divide the input space, and library offers you interesting options. For example, if one of your inputs is an angle, the library provides a special axis class for periodic input values. What's new: - Static polymorphism: The original version of the library solely used dynamic polymorphism to support different axis classes. This variant still exists, but the current version also allows you to use static polymorphism, implemented internally with boost::mpl and boost::fusion. This provides a speed-boost, which makes this library faster than the open-source competitors I tested (CERN's ROOT framework, the GSL, and numpy.histogram), in addition to the enhanced flexibility. - Arbitrary-precision counters: Counter overflow is now completely avoided by switching automatically to boost::multiprecision::cpp_int when the capacity of standard integer types is exhausted. - Extensibility: The library is now much more extensible and configurable. All relevant behaviour can be exchanged by using another (possibly user-defined) policy. The library provides default trade-offs that should work for almost everybody, but you can chose your own trade-offs. The new features were inspired by comments I got from the community. Now I am again at a point where I see the library in a very solid state. Best regards, Hans

1 0