March 2016 - Boost - lists.preview.boost.org

[Fit] About supported C++ version
by Vicente J. Botet Escriba 16 Mar '16

16 Mar '16

Hi, I was wondering if Boost.Fit shouldn't be a library as Boost.Hana, a library that makes use of the last C++ version and avoids as much portability issues as possible. Which C++14 features will make the library simpler? Which adopted C++17 features will make the library simpler? Which other C++ features would be missing? Paul I guess that you are using a C++11 compiler and want to support this version, could you confirm? Best, Vicente

2 3

Providing means to verify integrity and authenticity for releases
by Daniel Hofmann 16 Mar '16

16 Mar '16

The current download page at > http://www.boost.org/users/download/ redirects the user to SourceForge for downloading sources and / or binary Boost distributions. SourceForge can no longer be trusted as a hosting platform, as you can for example see following this thread > http://lists.boost.org/boost-users/2016/02/85662.php where a user was tricked into downloading some arbitrary binary while downloading a Boost release. Unfortunately there does not seem to be a secure and convenient way to download Boost releases. Although Github's Boost "releases" can be found at > https://github.com/boostorg/boost/releases but those are only repository snapshots, from which you can not even build a Boost distribution. And whereas the Boost 1.60 rc1 announcement mail at least provides checksums > http://lists.boost.org/boost-users/2015/12/85435.php The official 1.60 release announcement mail does not > http://lists.boost.org/boost-users/2015/12/85467.php Correct me if I'm wrong, but there is no way for obtaining a Boost release and verifying its integrity and authenticity. The only option I'm seeing is recursively cloning all Boost repositories from Github and building a release by myself. Can we please change this situation? Here are some options that come to mind ordered by amount of effort: - Providing checksums - Educating users on the Downloads page - Signing releases with a trusted Release Team key - Changing the hosting platform Cheers, Daniel J H

7 8

[ann] C++ Archive Network
by Egor Pugin 16 Mar '16

16 Mar '16

Hi, I'd like to present my project - C++ Archive Network (or simply CPPAN). You can consider it as (yet another) C/C++ package manager. In the beginning it was targeting C++ Modules, but it seems it can handle many current C/C++ projects. You can read more information about idea and motivation from links below (see docs). This is an alpha release (0.1.2). I'm announcing it only here to get initial feedback (but still boost community is large enough). As always the general idea is to create programs faster, to reuse and share your or anyone's code. But specifically here: source only packages (no tools, no tests in distribution pkg - keep all your stuff in your repos), Modules-like paths (org.boost.algorithm), semantic versioning (semver.org), zero-conf. projects, all-or-nothing dependencies (no optional deps.) and some other convenient features. At the moment CPPAN works only with CMake. It generates files that you include to your project (see docs). To be closer to boost and modern C++ community I added some popular projects as demo versions: - boost 1.60.0 - all projects - some core parts work (filesystem, thread, log, asio etc.), did not tried less used libraries. - new boost libs: coroutine2 (added but not set up, so does not works), dll - boost incubator libs: fit, DI - you can try them faster during reviews - gsl, range-v3, mach7, sqlpp11 (and connectors) - some modern libs - concepts libs: cmcstl2, text_view - so users can try and adopt new C++ features faster - google's: gtest,gmock,protobuf, recent 'highwayhash' lib - sqlite3 (3.11.0) - zlib, bzip2 - libressl - image libs: libpng, tiff, gif, webp, some others - libpqxx Most of them just works. Almost all dependencies are met. In boost.* I do not untangle the core dependencies, so base dependency-ball is quite big. I believe that library authors can eliminate unneeded deps better. Links: https://cppan.org/ - website https://github.com/cppan/cppan - client, use issues for feedback https://github.com/cppan/cppan/wiki - docs https://github.com/cppan/demo_project - example project that uses cppan https://github.com/cppan/packages - example packages (config files) https://github.com/cppan/packages/blob/master/boost/boost.cppan - base boost config file (big list of deps, probably can be shorter) --- ps. I'm not writing about pros. and cons. Both are present. Just give CPPAN a try and we'll see how we can improve it. -- Egor Pugin

5 5

Re: [boost] [Block Pointer] Benchmarks
by Glen Fernandes 15 Mar '16

15 Mar '16

On Sun, Mar 13, 2016 at 1:02 PM, Phil Bouchard wrote: > Thanks for your help. > > So block_ptr<> wouldn't be a drop-in replacement for shared_ptr<> but an > add-on for: > - complex containers, > - neural networks, > - C# / Java / Javascript engines, > - etc. > No problem. Also renaming the thread to reflect the current benchmarks (since it doesn't appear that block_ptr is faster than shared_ptr where creation is involved). 1. Gathering these benchmarks is always useful, even if block_ptr was not designed to be a drop-in replacement for share_ptr. So you had the right idea, even if the execution needed some work. It's important to get the execution correct, though, otherwise the results are not meaningful - which is where I (and I believe Rob, also) was trying to steer you. 2. Looking at the numbers you obtained after modifying my benchmark example, they are close enough that at least you could say "Using block_ptr over shared_ptr won't be a significant performance loss": > unique_ptr (new): 47.7686 > unique_ptr (make_unique): 46.8545 > shared_ptr (new): 77.8261 > shared_ptr (make_shared): 50.8072 > shared_ptr (allocate_shared_noinit): 33.021 > block_ptr (new): 69.6554 3. There are more benchmarks beyond just creation (though creation is likely the most meaningfully expensive one). Copying overhead might be one: I haven't looked at what is involved in copying a block_ptr, but some work happens when you copy a shared_ptr. 4. shared_ptr by way of allocate_shared allows creation to not involve 'new' expressions, or even a call to '::operator new(std::size_t)' at all. i.e. For those C++ projects that have a requirement for all dynamic allocation in their project to involve some stateful custom allocator instances of some stateful custom allocator type, they can still use shared_ptr (with allocate_shared). Is this possible with block_ptr? I hope to take a look at the block_ptr motivation, design, and implementation when I have some time next week. The title of the thread caught my attention; "X is 600% faster than Y" always has a high excitement potential. Glen

8 16

[Block Pointer] Update
by Phil Bouchard 14 Mar '16

14 Mar '16

Hi, - So I've restructured all the code in the correct namespaces boost::smart_ptr & boost::smart_ptr::detail: https://github.com/philippeb8/block_ptr/tree/master/include/boost/smart_ptr - I am now using another smart pointer to refer to proxies because it is safer but the code is 15% slower than without it (now ~= shared_ptr<>): make: auto_ptr: 26211292 ns shared_ptr: 27291607 ns block_ptr: 61097868 ns new: auto_ptr: 23240569 ns shared_ptr: 48016207 ns block_ptr: 55554121 ns - Because of the removal of the proxy optimization there is a new caveat; if you assign an rvalue (temporary pointer on the stack) to a pointer on the heap (opposite of normal heap object assigned to stack pointer) then there the behavior will be undefined. I am looking to fix it or throw an exception but for now it's better not to use rvalues when assigning to pointer living on the heap as such: https://github.com/philippeb8/block_ptr/blob/master/example/t100_test1.cpp#… Regards, -Phil

2 13

[Fit] formal review ends today, 13th March.
by Vicente J. Botet Escriba 14 Mar '16

14 Mar '16

Hi, The formal review of Paul Fultz II's Fit library ends today, 13th March. If you had not time to do the review and you plan to do it, please let us know so that we see if the review can be extended. Up to now we had 3 formal review (2 for conditional acceptance and 1 against, not now). I have not done a review myself, but I have created a lot of issues on Github. Best regards, Vicente Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both `constexpr` initialization and `constexpr` evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: * Function Adaptors and Decorators: These enhance functions with additional capability. * Functions: These return functions that achieve a specific purpose. * Utilities: These are general utilities that are useful when defining or using functions Fit has been tested on gcc 4.6-4.9, clang 3.4-3.7, and Visual Studio 2015. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - 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? More information about the review process can be found here:http://www.boost.org/community/reviews.html We await your feedback!

4 6

[Fit] Review
by Zach Laine 13 Mar '16

13 Mar '16

- Whether you believe the library should be accepted into Boost Yes, conditionally. * Conditions for acceptance I think the documentation and naming issues I raise below, and those filed on GitHub by me and others should be addressed before acceptance. Also, the ADL issues that Steven Watanabe alluded to previously need to be fixed. After that, I think it should be re-submitted. - Your name Zach Laine - Your knowledge of the problem domain. I do generic programming regularly, and have done for years. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design I think it's good. I particularly like the fact that it attempts to keep everything constexpr- and SFINAE-friendly wherever possible. I *really* like reveal() and failure(). Too few TMP-heavy libraries pay attention to providing good error messages. I have no problem with the constness requirements on Callables used throughout Fit, as was discussed previously. I even consider this a feature, allowing me to detect non-const Callables, which are almost always an error on my part. This is especially true since std::ref() and mutable_() let me explicitly choose how to handle mutable Callables, in a way that is also explicit at the call site. There are a number of adaptors that I find have obscure names: by() is a projection; why not call it project()? compress() is defined in terms of "fold", with a link to the Wikipedia page for same; why not call it foldl()? Similarly, reverse_compress() should be foldr(). flow() is a super obscure name! Why is this not reverse_compose() or similar? indirect() could more easily be understood if it were called deref() or dereference(). I don't feel as strongly about partial(), but I think it might be clearer if it were called partial_apply() or curry(). conditional() should be called invoke_first(), call_first_of(), or similar. I find it too easy to confuse with if_(). * Implementation I only briefly looked at the implementation, and only a few adaptors at that. What I saw did not leave me any concerns in particular. However, I *am* concerned by Steven Watanabe's claim that the library is ADL-unsafe. He did not state exactly why that I could tell, but this needs to be addressed if so. * Documentation The Quick Start section is good at showing a compelling motivating case for using the library. The result at the end of the section looks like a very good start on a "Scrap Your Boilerplate" solution for simple, dump-style printing. It's relatively easy to read and write. The documentation is what needs the most work, from what I've seen. The Quick Start is quite nice, but then there are some things that are underexplained in the subsequent Overview and Basic Concepts sections. For instance, why are these macros used everywhere and what do they do? They should be used for the first time after showing what the expanded code looks like. This will justify their use for those users that want them, and show those that don't what they can write instead. Others have written during the review that they don't understand why this library is useful. I think this is simply a documentation failure. I find the printing example from the Quick Start compelling, but perhaps Paul could show how it would have to be done if hand-written (even if only partially). Also, Paul has told me offline that there are a small number of primitive operations on which everything else is built (pack, unpack, and apply, IIRC). Perhaps show how those can be used to implement the other adapters, and how hard they are to write yourself. Showing how at least some of the library can be used as fundamental building blocks would go a long way. Some specifics. I have read the online docs before, and I put several bugs into the GitHub page for what I consider insufficient examples or explanations. Some new points, though: I think alias() is in bad need of a motivating example. I don't understand the distinction between lazy() and protect() just from the descriptions. In particular, this is what protect()'s docs say: '' The protect function adaptor can be used to make a bind expression be treated as a normal function instead. Both bind and lazy eargerly evaluates nested bind expressions. The protect adaptor masks the type so bind or lazy no longer recognizes the function as bind expression and evaluates it. '' I don't know what "masks the type" means here. This really needs an example. * Tests I did not run the tests, and just sort of spot-checked them. They seem a bit thin. In particular, one of the ones I looked at was conditional(). This one seems like it is needs more coverage, including thorny ones that must be kept working when maintenance occurs. There are probably others adapters that need similar treatment. Also, consider this -- Steven pointed out this as a failure case: boost::fit::conditional(identity(), identity())(0); and Paul says that it is supposed to fail, and that this failure is a feature, not a bug. If so, a minimal use like this that fails to compile needs to be added as a fail-compile test (and of course this intention should be documented). * Usefulness I think the library is very useful. There seem to be some things in there that use of which might be deemed a bit clever (not the good kind), like infix(), but then there are things like conditional() that I can see being *extremely* useful. - Did you attempt to use the library? If so: Yes. * Which compiler(s) Clang 3.6 * What was the experience? Any problems? I found I could gin up quick uses of things like conditional() (the most interesting adaptor for my purposes) in a short period of time. It was quite straightforward. - How much effort did you put into your evaluation of the review? About 5 or 6 hours. Zach

9 23

Alternative names to Boost.Fit
by paul Fultz 13 Mar '16

13 Mar '16

Hello All, Boost.Fit is a function utility library, however, the name currently doesn't have anything with this. I originally chose the name because it started with F(for function) and it was short and sounded nice. However, there could be some names(or abbreviations) that more adequately describe the library. Here are some alternatives that are short: - Boost.FP - Boost.FPL - Boost.Fun - Boost.FN Of course, I prefer the Boost.FN name. Names like Boost.FP or Boost.FPL could imply that it provides full functional constructs whereas Boost.Fit does not and is mainly focused on functions. Either way, this is something reviewers could consider as they review the library as I am not strongly tied to the name Boost.Fit. Thanks, Paul

13 27

[Block Pointer] Up to 600% faster than Shared Pointer
by Phil Bouchard 13 Mar '16

13 Mar '16

- I made the proxy explicit. Now it can be used 3 different ways: 1) Clothesline style: block_proxy x; block_ptr<int> v = block_ptr<int>(x, new block<int>(11)); block_ptr<int> w = block_ptr<int>(x, new block<int>(12)); 2) Root style: proxy_ptr<char[9]> u = proxy_ptr<char[9]>(new block<char[9]>()); 3) Container style (very easy to write containers now): struct list : block_proxy { public: list() : root(*this) {} [...] private: block_ptr<node> root; }; - I removed the capacity to unify sets. Why? Because it's faster & cleaner without it. - If we use fastblock<>() then the speedup can go up to 600% compared to shared_ptr<>: new: auto_ptr: 23174753 ns shared_ptr: 49726615 ns block_ptr: 7812659 ns - Once again all the examples can be found here: https://github.com/philippeb8/block_ptr/tree/master/example - And the pointer itself here: https://github.com/philippeb8/block_ptr/blob/master/include/boost/smart_ptr… Regards, -Phil

3 18

32/64 library name conflict under Windows?
by Peter Dimov 12 Mar '16

12 Mar '16

I remember that we discussed this problem before: C:\Projects\boost-git\boost>b2 --with-system toolset=msvc-10.0 address-model=32,64 [...] error: Name clash for '<pstage\lib>libboost_system-vc100-mt-gd-1_61.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <address-model>32 error: - <address-model>64 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. but don't remember what we concluded. Will we support building both 32 and 64 bit libraries under Windows? At present if I want to have an IDE project that has both Win32 and x64 configurations I need to build the 32 bit libraries, move them out of stage/lib somewhere, then build the 64 bit libraries, then move them out of stage/lib to somewhere else, and set my library directories in the IDE accordingly. It would be much more convenient if 32/64 were encoded into the name, so that I can leave my library path to point at stage/lib and rely on autolink to choose the right .lib file automatically, like it works today for the other options (debug/release, static/dynamic runtime).

14 25