noma

Would shipping all boost dependencies in thirdparty and integrating them directly into the CMake build be an option for you? Boost PP is header only, so shouldn't matter anyways.

Note: as discussed yesterday for C++ 17: ```cpp template using f2f = ham::function; f2f(args...) ```

So we have: ```cpp f2f(function, args...); // original syntax: BOOST_PP_OVERLOAD for portability and no compiler warnings f2f(function)(args...); // C++11, still Macros, but nor variadic macro necessary f2f(args...); // C++17, no...

With respect to the standard library's `std::function`and `std::bind` are closest relatives, `f2f` is very similar to bind, while the result is close to std::function: For C++17 I'd propose the following:...

Removed Boost Program Options in favor of header only CLI11 lib. Only Boost PP remains, but is header only and shipped in thirdparty folder, for C++11/14 compatibility.

The uninitialised bytes are probably a result of the internal buffer size and the actually allocated buffers size (one page by default). It wouldn't make much sense to initialise the...

Should be possible, only the `operator[]` is non-const, but I think it could be const too, as it only allows changing the state of the pointee, not the pointer itself......

`new_buffer` is a functor intended to be transferred and executed on the remote side, the `allocate` function is built on top for convenience. User's could manually use it, if they...

@Kazhuu thanks for the benchmark results. Have you tried playing around with explicitly setting `POCL_TBB_PARTITIONER` as described in the [doc](https://github.com/new2f7/pocl/blob/6efa2d06a76e0d9982fb693269069c011b56b55f/doc/sphinx/source/tbb.rst)?

Any ideas on how to make it vectorize? Can't see why OpenCL with auto vectorisation across work-items would not vectorise that, or maybe I have a wrong idea on PoCL's...