December 2014 - Boost - lists.preview.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

[variant] Opinion on boost::safe_get<> and default boost::get<> behavior
by Antony Polukhin 18 Dec '15

18 Dec '15

Hi all, I'm in doubt and would like to hear opinions on the following issue. boost::get for boost::variant was not making any compile time checks, resulting in runtime errors where a compile time error must be: boost::variant<int, string> v(100); boost::get<bool>(&v); // returns NULL instead of compile time error boost::get<bool>(v); // throws exception on runtime instead of compile time error Now we have an implementation of compile time checked get in a separate branch at git: boost::variant<int, string> v(100); boost::safe_get<bool>(&v); // compile time error boost::safe_get<bool>(v); // compile time error boost::unsafe_get<bool>(&v); // returns NULL instead of compile time error boost::unsafe_get<bool>(v); // throws exception on runtime instead of compile time error I'm in doubt, what the default behavior of boost::get must be: * safe_get behavior is much closer to Standard Library behavior (just like std::get for tuples) and allows to avoid errors in user code * unsafe_get behavior is same as behavior of old boost::get and won't break user's code if boost::get is used in some generic contexs What's your opinion? -- Best regards, Antony Polukhin

10 13

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

Arguing about names in Boost libraries
by Edward Diener 06 May '15

06 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

[SORT] Parallel Algorithms
by Francisco José Tapia 26 Mar '15

26 Mar '15

Sorry by the delay, As promised, the sorting parallel algorithms On my computer (Quad Core) the GCC std::sort and stable_sort are slight faster than my version of intro_sort and merge_sort (stable sort is a synonym of merge_sort). In other computer with an Intel I3, my algorithms are slight faster than in the GCC version. Trying to optimize the parallel implementation. I modified the parallel version for to use the std::sort and std::stable_sort. The parallel_sort version response good, but the parallel_stable_sort increase the time around a 60% compared with the version with countertree::parallel_merge_sort . After many test, I discover the cause of the problem. The demonstration is in the test_stress_sort_01.cpp. In this program we have a big vector of 100 000 000 elements uint64_t. The program make parts of the same size for each HW core. On my computer 4 parts and 4 cores. The program execute the part sequentially checking the time, and after do the same but in parallel, each thread sort a part, and check the time. This is done with the std::stable sort and countertree::merge_sort. The data input is the same for all. The next lines are the result show max. OpenMP threads: 4 (4 processors) Sort of 100000000 elements in a vector --------------------- Random elements, few repeated ( rand() )----------------------- Stable Sort Part 0 secs :2.77955 Part 1 secs :2.75015 Part 2 secs :2.76068 Part 3 secs :2.76284 Parallel Sort secs :8.49796 Countertree stable sort Part 0 secs :2.72802 Part 1 secs :2.71614 Part 2 secs :2.72074 Part 3 secs :2.722 Parallel Sort secs :4.80692 Surprisingly the parallel sort with countertree::stable_sort is much more faster than the sort with std::stable_sort in the GCC 4.8 and 4.9 compiler. This is the secret of the speed of the countertree::parallel_merge_sort. This is very important, because when the size of the elements is small, the GCC and the countertree algorithms have similar performance. But when the size of the elements grow, the std::stable sort is slower than the countertree::merge_sort. This difference is increased in the parallel version. The next lines are part of benchmark_sort_05.cpp *************************************************************** Sort of N = 6250000 elements of size 128 ***************************************************************** Random elements, few repeated ( rand() )----------------------- STL std::sort :2.9188 secs countertree::intro_sort :2.87864 secs parallel::sort :2.46113 secs tbb::parallel_sort :1.86458 secs countertree::parallel_sort:1.89263 secs std::stable_sort :8.77963 secs countertree::merge_sort :5.70694 secs parallel::stable_sort :8.03946 secs countertree::parallel_merge_sort :4.90815 secs I have in mind a new version of the stable sort in order to improve the speed, reducing the number of internal copy of elements. I hope to have time in Christmas, but I can't guarantee. If the results are the expected I will send you You have too, a version of indirect_sort, which sort pointers to the elements, and at end sort the elements according the pointers. You can replace any sort algorithm by their indirect version, obtaining the same results, with the only difference of the time needed. You have a benchmark_indirect_sort.cpp where see the comparison of the time needed of several sort methods and their indirect version with elements of different size. This code is a preliminary version, done for my countertree library. If you consider useful, I will change the name space and document the code, the algorithms and the ideas obtained from the benchmarks. Please feel free for ask me any question or for to modify or change anything. The goal is to provide good sort methods to the users. In the zip file you have the code and a file with a description of each code. Yours

5 20

[test] boost.test owner unresponsive to persistent problems for multiple years
by legalize+jeeves＠mail.xmission.com 18 Mar '15

18 Mar '15

[Please do not mail me a copy of your followup] See <https://svn.boost.org/trac/boost/ticket/10888> and <http://stackoverflow.com/questions/5209625/boost-test-error-messages-are-no…> Both contain a fix for this. On stack overflow the proposed fix is literally a single line change. This has been a problem for about 5 years and these simple fixes don't make it into the library. I'm sorry, but IMO this just isn't acceptable behavior for an owner of a library. Four years ago the maintainer made a comment on stack overflow thread to file a ticket on trac and then simply dropped the issue there as far as I can tell. That isn't proactive behavior, particularly when the stack overflow thread contains the fix. I know what you're going to say "the trac ticket was just filed a few days ago", but that's simply me pushing hard on something that should have been fixed around 2010. The problem has been known FOR FIVE YEARS and is EASY TO FIX. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

24 77

[build] b2 headers broken?
by Eric Niebler 02 Mar '15

02 Mar '15

I just updated to the latest develop. I ran bootstrap, then nuked my boost directory and reran b2 headers. Worked fine. Then I changed directory to libs/proto/test and ran ../../../b2 mem_ptr to run a test. Here's what I get: f:\modular-boost\libs\proto\test>..\..\..\b2 mem_ptr Performing configuration checks - symlinks supported : no - junctions supported : yes - hardlinks supported : yes ...patience... ...patience... ...found 4951 targets... ...updating 441 targets... common.mkdir ..\..\..\bin.v2\libs common.mkdir ..\..\..\bin.v2\libs\proto common.mkdir ..\..\..\bin.v2\libs\proto\test common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0 common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug\link-static common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug\link-static\threading-multi link.rm ..\..\..\boost\mpl common.mkdir ..\..\..\boost\mpl link.hardlink ..\..\..\boost\mpl\print.hpp Hardlink created for ..\..\..\boost\mpl\print.hpp <<===>> ..\..\mpl\include\boost\mpl\print.hpp <snip> link.rm ..\..\..\boost\numeric\conversion link.hardlink ..\..\..\boost\numeric\conversion\conversion_traits.hpp The system cannot find the path specified. if exist "..\..\..\boost\numeric\conversion\conversion_traits.hpp" del "..\..\..\boost\numeric\conversion\conversion _traits.hpp" mklink /H "..\..\..\boost\numeric\conversion\conversion_traits.hpp" "..\..\numeric\conversion\include\boost\numeric\ conversion\conversion_traits.hpp" ...failed link.hardlink ..\..\..\boost\numeric\conversion\conversion_traits.hpp... link.hardlink ..\..\..\boost\numeric\conversion\int_float_mixture_enum.hpp The system cannot find the path specified. For some reason, b2 thinks it needs to rerun b2 headers, but it does a crap job of it and dies. What's going on? Eric

4 6

PDF versions of Quickbook generated documentation - Do you like the serif font?
by Paul A. Bristow 14 Jan '15

14 Jan '15

I've noted that for documentation using the Quickbook toolchain, we use a serif font (Times Roman?) for the PDF, but a sans serif for the equivalent HTML version. Is there a reason for this? Should they not be the same font? (So that they look the same?) Which do we prefer? Should we change either or both? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

2 2

Boost.Sort library hierarchy and namespacing
by Steven Ross 08 Jan '15

08 Jan '15

For the Boost.Sort library, I'm planning to add these (non-detail) files: boost/sort/sort.hpp boost/sort/spreadsort/spreadsort.hpp boost/sort/spreadsort/integer_sort.hpp boost/sort/spreadsort/float_sort.hpp boost/sort/spreadsort/string_sort.hpp Should all of these be in the boost::sort namespace? It seems silly to have a boost::sort::spreadsort namespace when there are only 5 publicly-visible functions in it. I actually can't imagine how of these names will conflict with names in other boost libraries, but using a boost::sort namespace appears conventional. Are there any objections or concerns based on this? Once this is done, I'd like to integrate this library into the boost build and testing system for the next appropriate release (I test it currently with modular boost).

2 2

Directory structure not quite right yet?
by Peter Dimov 08 Jan '15

08 Jan '15

Typically, when some library is installed in, say, $LIB, its headers reside in $LIB/include and its .a/.lib files in $LIB/lib. Our libraries, when built, go to $BOOST/stage/lib, which is close enough. But our header directory is just $BOOST, which doesn't seem right, as the whole of Boost is accessible through it. It makes sense, at least to me, to have the headers in $BOOST/include/boost, instead of just $BOOST/boost. The transition to Git would have been a good time to switch to that - there were enough other changes to the structure. I'm not saying that we should switch right away or something like that, but am I the only one to whom such a switch (at some unspecified time in the future) seems a good idea?

12 41

[Tick] Universal quantified concepts/traits
by Vicente J. Botet Escriba 06 Jan '15

06 Jan '15

Hi, I'm trying to represent the concept of a mathematical Functor (as in Haskell) with Concept Lite. Here is what I want to express: A Functor W is a type constructor for wrappers of another type T providing a function map taking a function (T) -> U and a W<T> and returning a W<U>. Here is how I think that could be done with Concept Lite. If I understand the proposal correctly we need to add the type T and the function parameter to the concept. concept Functor<typename W, typename T, typename F > = requires { using WT = ApplyType<W, T>; // type constructor using U = ResultType<F, T>; using WU = ApplyType<W, U>; Function<F, U, T> && requires (F f, WT wt) { WU { map(f, wt) }; } }; But this is not exactly what I want to conceptualize. The wrapped type T and the function F should be universally quantified, that is, the concept concerns only the type constructor W: Functor<W>. I have a problem introducing the universal quantification of T and F. I don't know how to do it without using again a template. concept Functor<typename W> = template <typename T, typename F> // universal quantification on T and F requires { using WT = ApplyType<W, T>; using U = ResultType<F, T>; using WU = ApplyType<W, U>; Function<F, U, T> && requires (F f, WT wt) { WU { map(f, wt) }; } } }; But this is not valid code, isn't it. Is there something wrong with this kind of concepts? What would be the best way to conceptualize this kind of concepts with the Tick library ? Best, Vicente

3 5

[status] explicit-failures-markup.xml edit permissions
by Vladimir Batov 05 Jan '15

05 Jan '15

On some compilers some of my SFINAE-related "convert" regression tests fail. So, I tried to update status/explicit-failures-markup.xml to explicitly mark those test failures rather than masking/disabling them. For understandable reasons I have no permissions to modify the file, so that update of mine was denied. I tried contacting Daniel James as he often helps me with build matters but he is seemingly unavailable. I am hoping someone else might have edit-permissions to the file and be kind enough to add the following code (below) to the file for me? My apologies for such a wide post or if my request is misdirected. Your help in the matter is much appreciated. Thanks, Vladimir.  <library name="convert"> <test name="convert_test_has_begin"> <mark-failure> <toolset name="msvc-8.0*"/> <toolset name="msvc-9.0*"/> <toolset name="msvc-10.0*"/> <toolset name="msvc-11.0*"/> <note author="Vladimir Batov"> The relevant SFINAE support is broken in MSVC up to version 11. </note> </mark-failure> </test> </library>

3 2

[functional] Is anyone maintaining it?
by Andrzej Krzemienski 05 Jan '15

05 Jan '15

Hi Everyone, I can see that the pull request I submitted at https://github.com/boostorg/functional almost three months ago has not been acted upon. Is the library still maintained? Regards, &rzej

2 1

[filesystem] Junction support on Windows?
by Peter Dimov 02 Jan '15

02 Jan '15

Filesystem provides support for hard and symbolic links, but on Windows, hard links do not work on directories and symbolic links do not work for the majority of users because they require elevation by default. That is why, for example, "b2 headers" was changed to also use junctions, if possible. But if I, for another example, want to replicate "b2 headers" from a C++ program using Filesystem, I can't, because it offers no junction support. Should create_directory_symlink be enhanced to create a junction, if CreateSymbolicLink is not available or fails with ERROR_ACCESS_DENIED?

2 2

[filesystem] resize_file_api leaks a HANDLE
by Peter Dimov 02 Jan '15

02 Jan '15

... when SetFilePointerEx or SetEndOfFile fails. BOOL resize_file_api(const wchar_t* p, boost::uintmax_t size) { HANDLE handle = CreateFileW(p, GENERIC_WRITE, 0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); LARGE_INTEGER sz; sz.QuadPart = size; return handle != INVALID_HANDLE_VALUE && ::SetFilePointerEx(handle, sz, 0, FILE_BEGIN) && ::SetEndOfFile(handle) && ::CloseHandle(handle); }

3 2

[compute] Review
by Yiannis Papadopoulos 01 Jan '15

01 Jan '15

Hi, This is my review of Boost.Compute: 1. What is your evaluation of the design? It seems logical to me. It is effectively a wrapper around OpenCL that provides implementations of higher-level algorithms, and allows interoperability with OpenCL and OpenGL. The Boost.Compute name is a bit misleading, as Boost.Compute supports only OpenCL-enabled devices. 2. What is your evaluation of the implementation? There is some code duplication (e.g. type traits) and various other bits and pieces that can be moved to existing Boost components. I think there should be some effort spent towards that. It seems that performance is on par with Thrust. However, there are other libraries out there (e.g Bolt) and multiple devices, so there has to be a more extensive experimental evaluation to say decidedly that it is a good implementation. 3. What is your evaluation of the documentation? Overall, it is pretty good. Given the complexity of the accelerator programming model, a few more elaborate examples in the tutorial would be welcome. 4. What is your evaluation of the potential usefulness of the library? This is difficult to answer. A lot of work has been put in this library and it seems the way to go. The interfaces are clean, the code looks solid and the developer willing. However, there is limited vendor support, there are not enough benchmarks and there are other alternatives that they have both. Given that Boost.Compute is targeted to users that know a thing or two about performance, I don't know how they can be convinced to consider using Boost.Compute against Bolt or Thrust. 5. Did you try to use the library? With what compiler? Did you have any problems? I did using an AMD 7850 on Linux with gcc 4.8. The few examples I tried, compiled and ran fine. 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I went over the documentation, I glanced over the code and ran a few examples. 7. Are you knowledgeable about the problem domain? I'm in the HPC field. I have extensive experience with MPI, OpenMP, pthreads, and less with TBB, CUDA and OpenCL. 8. Do you think the library should be accepted as a Boost library? This will be a maybe. It is a well-written library with a few minor issues that can be resolved. However, why would someone use Boost.Compute against what is out there? Average users can resort to Bolt or Thrust. Power users will probably always try to hand-tune their OpenCL or CUDA algorithm. How can we test it and prove its performance? Regards, Yiannis

5 7

[compute] review
by Vicente J. Botet Escriba 01 Jan '15

01 Jan '15

Hi, I have no time to do a complete review. Anyway here it is my minimal review *1. What is your evaluation of the design?** *** I would prefer that the algorithms take as first parameter the queue (which could be abstracted to an asynchronous executor). The performances let think that there is no interest in using the library for containers having less than 10^4/10^5 elements. Even if this is considered a low level library, the documentation should show how a library writer could make use of the provided interface to provide a higher one. I would prefer that the library make use of std::future or boost::future class instead of adding an additional one. Do the author tried to make use of the existing futures? if yes, which problems were found? I'm missing a range interface to most of the algorithms. I suspect that as this is a C++03 library it doesn't take advantages of some interesting C++11+/C++14 features. It is not clear which operations are synchronous, which ones could block, ... In order to get the native OpenCl handle I suggest to name the function get_native_handle instead of get. *2. What is your evaluation of the implementation?* I've not see at the implementation. *3. What is your evaluation of the documentation?* The documentation lacks of some core tutorials. I was unable to have an idea of what a context is, what can be done with a command_queue, what is a Kernel, a pipe, ...? Does it mean that the user must know OpenCL? The reference documentation should follow he C++ standard way, including pre-conditions, effects, synchronization, throws clauses. I would appreciate a description of the algorithms used, how the parallelism is used? is this completely managed by OpenCL or do the library something else? *4. What is your evaluation of the potential usefulness of the library?** *** This is essentially an optimization library. It should be quite useful, but the performances results don't probe it. *5. Did you try to use the library? With what compiler? Did you have any problems?** * No.* *** *6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?** *** A glance. *7. Are you knowledgeable about the problem domain?* Yes and not. I don't know about OpenCL, but I'm aware of the current parallel proposals. *8. Do you think the library should be accepted as a Boost library? ** * As I have not taken too much time I'm unable to say that this library should not be included in Boost. So I vote to include it conditionally, subject to: * I would need some performances that probe the library is better than using standard STL containers in most of the cases. * The documentation should be completed with more tutorials and a better reference documentation. Best, Vicente

4 4

[compute] review
by Gruenke,Matt 31 Dec '14

31 Dec '14

> 1. What is your evaluation of the design? I agree with other comments made about synchronization. The design should be more explicit about what's asynchronous, and ideally utilize only one mechanism for synchronization. One approach that would have made this clearer is if high-level operations were actually objects that got posted to the command_queue. Regarding synchronization, I'm a also bit concerned about the performance impact of synchronizing on all copies to host memory. Overuse of synchronization can easily result in performance deterioration. On this point, I think it might be worth limiting host memory usable with algorithms, to containers that perform implicit synchronization to actual use (or destruction) of results. Give users the choice between that or performing explicit copies to raw types. Also, I agree with Thomas M that it'd be useful for operations to return events. That said, if you told me it doubled the overhead involved in dispatching operations, I'd suggest to make it optional through overloads or via a mechanism in the command_queue itself. > 2. What is your evaluation of the implementation? It seems a bit heavy to be header-only. I'd agree with Andrey Semashev, regarding thread safety, except I think it shouldn't be an option at all. That said, not all operations on all objects need be thread safe. I think the Boost.ASIO documentation provides a good example of how to express different thread safety limitations. Now, I haven't examined the use of thread-local storage, but do you feel there's a strong case to be made for the thread safety it's providing (especially, given that you seem to feel it's non-essential)? I'm a bit concerned about the use of type names ending in '_', such as float4_. Is this consistent with Boost conventions? I've only seen that used in other Boost libraries to denote class member variables. I didn't notice any unit tests specifically intended to verify exception-safety. I'd want to know that had been thoroughly vetted, before I'd consider using Boost.Compute in production code. Finally, based on the docs, it seems there's a bug in boost::compute::command_queue::enqueue_copy_image_to_buffer() and boost::compute::command_queue::enqueue_copy_buffer_to_image(). The region and origin parameters should be arrays, in the 2D and 3D cases. If this discrepancy is intentional, it should be noted. I haven't exhaustively reviewed the reference docs, so there might be other issues of this sort. > 3. What is your evaluation of the documentation? It needs more and better-documented tutorials (and I'm including the "Advanced Topics", here). Some of the reference pages could use more details, as well, especially concerning synchronization and exception usage. Regarding exceptions, there should be discussion of specifically what is invalidated by which kinds of errors. If any errors are non-recoverable, this should also be called out and perhaps derived from a different or additional baseclass (not a bad use case for multiple inheritance, actually). I agree with Mathias Gaunard that it would be helpful to discuss computational complexity, device memory requirements, and the various methods used to implement some of the algorithms. You could continue to omit these details on the simple algorithms, though. > 4. What is your evaluation of the potential usefulness of the library? This is my biggest misgiving, by far. In the very near future, I expect developers will opt for either SYCL (https://www.khronos.org/opencl/sycl) or Bolt (https://github.com/HSA-Libraries/Bolt) SYCL provides a modern, standard C++11 wrapper around OpenCL, with better concurrency control and support for integrating kernels inline. Bolt provides many of the same higher-level abstractions found in Boost.Compute, but with forthcoming support for HSA. To have the kind of lasting relevance and broad applicability to which all Boost libraries should aspire, I think Boost.Compute should be architected to support multiple backends. Though OpenCL support is currently ascendant, it's far from universal and is already flagging on some platforms (Nvidia, not the least). And HSA provides a foundation on which alternatives are actively being built. Most importantly, there exist multitudes of multi-core and multiprocessor systems which lack OpenCL support. It would be eminently useful to support these with such backends as thread pool, OpenMP, etc. And backends could be added to support new technologies, as they mature. > 5. Did you try to use the library? With what compiler? Did you have any problems? I downloaded and inspected the sources and some examples. I didn't have any questions or concerns that would be addressed by experimentation. > 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Review of the documentation, some sources, some examples, and a refresher on SYCL & Bolt. I also read all of the reviews and replies sent thus far. > 7. Are you knowledgeable about the problem domain? I've been developing production code for parallel and heterogeneous computing platforms for the majority of the last 16 years. I've followed OpenCL since version 1.0 was finalized. I've also submitted bug reports and minor patches for Khronos' official C++ OpenCL interface. > 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Not in its current state. The primary issue is that it's too OpenCL-centric. It should support more backends, even if these are just compile-time options. This is crucial for both current and lasting relevance. Beyond that, better concurrency control is crucial for optimum performance. If done well, it could even help further reduce usage errors. Matt ________________________________ This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.

13 63

Boost.Build files at superproject root
by Peter Dimov 31 Dec '14

31 Dec '14

Currently, the Boost root contains the following files: boost-build.jam boostcpp.jam boostcpp.py bootstrap.bat bootstrap.sh Jamroot which are part of Boost.Build and so their rightful place is in the submodule. Would it be possible to move them there, and leave only minimal forwarding shims (that would never need to change) in the superproject?

3 5

[compute] Review
by John Bytheway 31 Dec '14

31 Dec '14

Here's my review. 1. What is your evaluation of the design? The design of building on OpenCL seems sound, for the reasons Kyle has explained. The fact that it has real users is very encouraging. I don't really like the name (I was unable to guess what the library was about from the name), but it's not worth changing at this point. I am worried about the compile-time configuration with macros. I would hope that BOOST_COMPUTE_HAVE_THREAD_LOCAL could be read from Boost.Config. For the two features which require linking against other Boost libraries, my instinct would be to have them on by default, rather than off by default (that should be easier if and when Boost.Compute is part of the Boost distribution). It would be very nice to have range versions of all the algorithms. I find myself using the boost::range algorithms much more than the std:: ones these days. Similarly, it would be good to provide the safer 4-iterator versions of equal, is_permutation, mismatch (and any I've forgotten) as were added to C++14. Some minor things: - Consider renaming boost::compute::lambda to be consistent with one of the other placeholder-containing namespaces from std or Boost. (You can keep the old name as an alias for backwards-compatibility). - Why the default of .25 as the bernoulli_distribution parameter? - Did you consider using Boost.Predef for your version macro? 2. What is your evaluation of the implementation? Only looked at a couple of things while trying to understand the docs. 3. What is your evaluation of the documentation? Overall, not too bad. More tutorial would be good. In particular, something using some of the standard algorithms. Some concerns: - All the header links off <http://kylelutz.github.io/compute/boost_compute/reference.html> are broken. - All or most of the things in "See also" sections look like they ought to be links but aren't. - For all your function parameter documentation, the list of parameters seems to be sorted alphabetically by parameter name rather than in the order they are passed to the function. This is really weird... - As others have mentioned, some kind of complexity estimate or promise for the algorithms is very important. In particular it would be good to understand how much parallelism they take advantage of and how they ought to scale with device compute capability. - The warning about accumulate being slow for floats should be much more prominent. - <http://kylelutz.github.io/compute/boost/compute/copy.html> mentions copying from e.g. a std::list to a compute::vector. It would be nice if it gave some kind of indication as to how efficient we can expect such an operation to be. In particular, I guess it ought to do some kind of buffering on the host? - The way I normally copy into vectors is call v.reserve(...) and then copy to std::back_inserter(v). I tried that with a compute::vector and unsurprisingly it was very inefficient. I see you already warned about this in the push_back docs, but perhaps it should also be highlighted in the documentation of compute::copy. - Is there no version of inclusive/exclusive_scan or iota using an arbitrary associative operator? - <http://kylelutz.github.io/compute/boost/compute/includes.html> it's unclear whether the subrange has to be contiguous. - min_element and max_element should cross-reference minmax_element. - What source of randomness does random_shuffle use? - Why does reduce return its result through an OutputIterator? - <http://kylelutz.github.io/compute/boost/compute/remove.html> Does this really remove things or use std::remove semantics? You should clarify and document the return value. (Same with remove_if, unique) - I can see how sort_by_key might be useful, and I'm slightly surprised that there's no stable_sort_by_key (which seems like it would be more useful than stable_sort). Any particular reason? - The boost/compute/types headers docs seem to be broken or missing. In particular I couldn't find reference documentation for float4_ et al. - I was interested to see allocators, but the docs seem uninformative: <http://kylelutz.github.io/compute/boost/compute/pinned_allocator.html> - Given the confusion with std::future, you might want to clarify whether compute::future's destructor blocks. - Also, <http://kylelutz.github.io/compute/BOOST_COMPUTE_CLOSURE.html> doesn't explain what format the lists (arguments and capture) should be in. Preprocessor functions often take lists in other formats, such as a Boost.PP Sequence <http://www.boost.org/doc/libs/1_57_0/libs/preprocessor/doc/data/sequences.h…>, and your example only has one-element lists, so it's not enough to clarify this point. (To be clear: I'm not suggesting you should use Boost.PP sequences, merely that you should make it clear in the docs whether you are). - <http://kylelutz.github.io/compute/BOOST_COMPUTE_CL_CALLBACK.html> is empty, as is <http://kylelutz.github.io/compute/BOOST_COMPUTE_MAX_ARITY.html> - <http://kylelutz.github.io/compute/boost/compute/valarray.html> - presumably compute::valarray has overloaded arithmetic operators? Are they mentioned anywhere? - <http://kylelutz.github.io/compute/boost/compute/vector.html> the unusual behaviour of vector's size_t constructor (not initializing the elements) should be warned more prominently. - <http://kylelutz.github.io/compute/boost/compute/device.html> the documentation of the enum type in the synopsis seems to be messed up. Similarly memory_object. - <http://kylelutz.github.io/compute/boost/compute/function.html> I'm puzzled by this interface. What's the name for? Would one ever use this constructor rather than e.g. make_function_from_source? - <http://kylelutz.github.io/compute/boost/compute/field.html> My reading of this is that when you get the type wrong you are guaranteed some kind of meaningful error report, and not just undefined behaviour; is that right? Perhaps you should clarify. - I can't guess what atomic_min and atomic_max do. - The right arrow ('next') link from <http://kylelutz.github.io/compute/boost/compute/atomic_xor.html> is broken (looks like the docs for the placeholders don't work). - The iterators should state what iterator category they have. - I can't guess what svm_ptr is for. Later I discovered svm_alloc and svm_free. Is there an RAII way to manage these things? - What does default_device do if there are no devices? Do the various environment variables mentioned have any kind of precedence? (Probably linking to the corresponding OpenCL docs is sufficient for such questions). Do they have to be exact matches? Are they case-sensitive? - What does find_device do if the requested device does not exist? - Can you give examples for type_definition? My guess was that it did the thing which type_name later turned out to do... - BOOST_COMPUTE_ADAPT_STRUCT should state that it must be used at global scope (i.e. not within a function or other namespace). - Congratulations for getting compile-time detection of internal padding into BOOST_COMPUTE_ADAPT_STRUCT :). You might want to mention in the docs that this will be detected, so people don't worry too much. - It looks like the performance tests don't include the time for copying data to (and, where applicable, from) the device. You should mention this on the Performance page. - You should probably add C++AMP to your things compared with in the FAQ. 4. What is your evaluation of the potential usefulness of the library? High. I've wanted something like this in the past and not found this. 5. Did you try to use the library? With what compiler? Did you have any problems? I used it with g++ 4.8.2 in C++1y mode. Some quick tests seemed to work OK, and indeed I was able to sort some large vectors of scalars faster using boost::compute::sort than std::sort, which is nice. I was pleased to see that 64-bit integers were handled fine. 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Couple of hours reading and trying simple examples. 7. Are you knowledgeable about the problem domain? I have done a couple of small projects with CUDA, and am generally knowledgeable, but with no previous OpenCL experience. 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes. OpenCL seems to have fairly broad acceptance, but is rather difficult to use safely and with C++-isms. This library fills a useful niche. In an ideal world it will eventually be rendered obsolete by things like parallelism entering the standard library, but I doubt that will happen soon if at all. This provides a good solution now, and we shouldn't dismiss it simply because something sparkly is approaching, which may or may not turn out to be awesome and widely adopted. This library has clearly been a lot of work. Congratulations on making it this far, I hope the review is not too stressful :). John Bytheway

3 12

[system] Problem with boost::system::system_category() under QNX Momentics
by Piotr Orzechowski 31 Dec '14

31 Dec '14

At the beginning I must assure You that I've tried almost every solution from similar topics , still they didn't solve my issue. I'm building binaries from Boost 1.57 using **MinGW**. Boost libraries I'm using: *thread* and *system* build without any errors. I was trying: > toolset=gcc --target-os=qnxnto and toolset=gcc --target-os=qnx, both didn't work. I'm including correctly both libraries: > -lboost_system-mgw48-mt-d-1_57 -lboost_thread-mgw48-mt-d-1_57 after using: > `#define BOOST_SYSTEM_NO_DEPRECATED` I got rid of `boost::system::generic_category()` error, still I can't get rid of: > boost::system::system_category() I'm working in **QNX Momentics**. I'm totally out of ideas, I'm really looking forward for any help I can get.

2 2

Define to test for deprecated std::auto_ptr
by Fletcher, John P 31 Dec '14

31 Dec '14

I have some tests which are throwing up std::auto_ptr as deprecated with C++11. Is there a define that can be tested for in user code so that I can switch to std::unique_ptr when it is available? Something like this: #ifdef BOOST_NO_CXX11_UNIQUEPTR // use auto_ptr #else // use unique_ptr #endif Is there a general flag for C++11 or C++14 or is it all done on particular features? Thanks John

3 5

[compute] CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE
by Gruenke,Matt 31 Dec '14

31 Dec '14

I assumed there was some behind-the-scenes mechanism to maintain order of higher level operations, but I hadn't dug around to find them. I thought maybe there was an event object embedded in the device memory containers, used to track any pending writes to them, that could be added to the wait list of subsequent operations. But I don't see anything like this. So, will enabling out-of-order execution will break the higher level operations? Or am I missing something? Matt ________________________________ This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.

3 6

[compute] Review period starts today December 15, 2014, ends on December 24, 2014
by Antony Polukhin 31 Dec '14

31 Dec '14

Dear All, Review of the Compute library starts today on Mon 25st of December 2014 and will last for ten days. The Compute library provides a C++ interface to multi-core GPGPU and CPU computing platforms based on OpenCL. The project is hosted on GitHub at https://github.com/kylelutz/compute. Docs are available at http://kylelutz.github.io/compute/ Sources could be downloaded as a ZIP archive via https://github.com/kylelutz/compute/archive/master.zip Some pre-official reviews could be found in Boost Library Incubator: http://rrsd.com/blincubator.com/reviews/?library_id=669 Please, answer the following questions in your review: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And finally, every review should answer this question: 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. -- Best regards, Antony Polukhin

7 8

[compute] Review comments
by Asbjørn 30 Dec '14

30 Dec '14

Hi, not a proper review, just some comments from a library user based on studying documentation and writing a couple of simple programs using Boost.Compute on Intel's and NVIDIA's OpenCL implementations (i7 CPU and GTX970 GPU respectively). I used MSVC2013 for the tests. Some of these comments I've shared previously on this list, but I'm repeating them here for completeness. I have some background in heterogeneous development and OpenCL in particular, but I'm no expert. I found Boost.Compute easy to pick up and providing a nice C++ layer, with a nice mix of low and high level. Comments in no particular order: 1) As a library user and one who's not a C++ guru by any means, the error messages thrown up when passing incorrect parameters can be quite confusing. For example, first time I tried to use Boost.Compute I managed to not pass the ouput iterator parameter to transform(), so that the lambda expression ended up in that position instead. This resulted in several very confusing errors inside result_of.hpp, with no errors anywhere near my or Boost.Compute source code. It would be nice if the compilation could fail in more informative manners. 2) I did miss async versions of the algorithms, so it's possible to chain together multiple calls. Even though all the data sits on the compute device, the overhead of waiting for each operation to finish before queuing the next can make the compute gains completely irrelevant. 3) I think relevant calls should have a non-throwing form returning an error code, ala Boost.ASIO. 4) Threading has been mentioned in this list. At the very least the documentation should be updated to clearly state the thread safety of each call/class, ala Boost.ASIO. Beyond that I would like to be able to share a context between several threads, each which could contain their own queue and device. 5) If thread safety or similar important features requires a compiled part, I wouldn't mind Boost.Compute being non-header-only. Though if possible making it optional like other Boost libraries do would be great. 6) The tests, and preferably the performance tests as well, should have some way of testing all devices across all platforms. Currently they only test the default device on the default platform it seems. This is insufficient IMHO. 7) I'd like some way of defining user functions either as lambda expressions, raw OpenCL-C code via make_function_from_source or both, which can be used in lambda expressions for say transform(). Something like function<int (int)> sqr = _1 * _1; transform(inp.begin(), inp.end(), out.begin(), sqr(2 * _1 + 1)), queue); Overall I think Boost.Compute can be useful right now for some use-cases, and it has good potential to be significantly more useful with a bit more work. Just my 2 øre. Cheers - Asbjørn

4 5

[filesystem] imbue_utf8
by Peter Dimov 30 Dec '14

30 Dec '14

Since nowadays it's very common for programs to use UTF-8 for path encoding everywhere, I suggest that in addition to path::imbue( loc ), there should be path::imbue_utf8(), which imbues a UTF-8 codecvt facet. Since this is the default on Mac OS X, the implementation is already present, but the user has no way to get to it.

1 0

[config] Macro for detecting thread_local storage support
by Kyle Lutz 30 Dec '14

30 Dec '14

I have looked but been unable to find any macro in Boost.Config for detecting compiler support for the C++11 thread_local storage specifier. Does such functionality exist? I would like to use something like this to automatically detect compiler support for thread_local for use by the proposed Boost.Compute library. Currently I rely on the users defining BOOST_COMPUTE_HAVE_THREAD_LOCAL in order to enable support. Hopefully there is a better way? -kyle

2 1

Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years
by Dave Gomboc 30 Dec '14

30 Dec '14

I get the digests, so I'm quoting from a number of different emails on this thread in this message. > > Both contain a fix for this. On stack overflow the proposed fix is > > literally a single line change. > > The issue is addressed in devel branch with somewhat better fix > long long time ago. It is important that tickets be updated to reflect such information. > > If there are issues fixed in develop branch, it would help a lot > > to inform users by updating the tickets accordingly. > > Here is a blanket update message: at this point all the issues with > Boost.Test are fixed on devel branch ;). This doesn't help people who filed a ticket (perhaps years ago) but don't happen to catch this email. > > This has been a problem for about 5 years and these simple fixes don't > > make it into the library. > > This is going to be released as part of the effort of merging devel into > master. Now, when this happens depends only on docs upgrade. It seems that in addition to documentation upgrades/improvements there is at least also the issue of identifying all Boost.Test-related tickets that are currently outstanding, verifying that the issue raised within them is indeed resolved within the development branch (rather than just assuming this is true), and updating the ticket to reflect that the problem has been resolved in the development branch (though it should not be closed yet until a new Boost release comes out with the fix in place). > All in all "devel to master upgrade" is one target I really want to reach > and is what I plan to concentrate my effort on. You are still welcome to > help with this if you are up to it. Excellent! If it has really been five years (or even if it has been only one full year) since this last happened, then may I suggest that this should be your sole target for Boost.Test until this task is accomplished, that your target should be prior to the next major release of Boost, and that obtaining assistance be an important part of your plan to accomplishing this task within this timeframe? To that end, could you please provide for the Boost community a detailed outline of exactly what remains to be done in order for the merge of the latest Boost.Test to master to be completed? Please be clear about exactly what others can help with, and in the cases where you think nobody else can help you, why that is so. Please do so here on the mailing list rather than ask people to contact you privately about it, so that more people will know what remains to be done and may be willing to lend a hand so it can get done. > > 1. What are the reason(s) why-list_content is not (yet) > > added to the release? Is there any schedule for its release? > > I need to document all these new features to release new Boost.Test Can you provide a list of these new features alphabetically by name with a one-sentence description? Boosters can sign up for writing documentation paragraphs, can contribute them here, and you can collect and use them. > > Yes. I fully agree with this statement. I hope to get back to this list > > with more concrete schedule soon. And if you are interested to push this > > even sooner - please feel free to help. > > That's great news. I know a vast amount of work has gone into develop > and we'll all benefit when it finally gets merged into master. Yes, I'm > happy to support this effort as best I can. Feel free to contact me > off-list. Rather than contact people off-list, I urge you to get all of the outstanding work into the open and use this mailing list for co-ordination not only so that people can contribute without overlapping their effort needlessly, but so that the current status is visible to all of us. That last point is rather important: I know of projects that have chosen alternative testing frameworks simply because of the lack of visibility re: Boost.Test. > Thanks for working hard to move this forward. Boost.Test has always been > a critical library and as a result somewhat of a thankless task to > maintain given the constant risk of breakage across Boost as a whole. > Thanks for persevering. I absolutely concur with this. Your efforts are appreciated, Gennady! You've been shouldering the entire burden for too long. I think that by publicly coordinating and leading the remaining effort to get the latest Boost.Test onto master, you'll be able to achieve this goal more quickly. Dave

3 3

[filesystem] Request for help with unresolved tickets
by Beman Dawes 29 Dec '14

29 Dec '14

Boost.Filesystem has roughly 140 unresolved tickets, and far too many are more that a year old. Some are up to four years old. That's horrible, and entirely my fault. I really dislike processing most bug reports, so leave them until I have nothing else to do, which is roughly never. But a few bug reports are actually fun to process. These are the ones that provide a little test program that unambiguously illustrates the problem and includes full information about the compiler, platform, version of boost, etc. To encourage more such dream tickets, I've added a little bug reporting framework with docs to filesystem's develop branch. It depends on a new header (boost/detail/lightweight_test_report.hpp) that's been added to the detail library's develop branch. The hope is that this will lead to more test programs that make it easy to reproduce bugs to (1) speed my processing of tickets and (2) ease handing off tickets to other developers for fixes. There are several ways boosters can help: * Review and try out the instructions at http://boostorg.github.io/filesystem/issue_reporting.html. (Don't expect all links to work.) Were you able to easily follow these instructions? What would you like to see added or removed? * Look through the bugs in https://svn.boost.org/trac/boost/report/53, pick one you think would benefit from a test program, and add a test program as described in http://boostorg.github.io/filesystem/issue_reporting.html. (Do a git pull on develop branch of detail and filesystem libraries first.) Were you able to easily follow these instructions? What would you like to see added or removed? Thanks, --Beman

3 2

[multiprecision] [detail] [number_base.hpp] Ambiguous partial specialization for canonical_imp
by Sergey Sprogis 29 Dec '14

29 Dec '14

It looks like boost/multiprecision/detail/number_base.hpp header in one of the later trunk versions has ambiguous partial specialization problem which Oracle Studio 12.4 C++ compiler detects. It can be also detected by gcc-4.8.2 as small 35 lines independent test case below made from this header shows. gcc -c -std=c++11 t.cc # gcc-4.8.2 compilation t.cc:17:62: error: ambiguous class template instantiation for 'struct canonical_imp<number<cpp_dec_float<50u>, (expression_template_option)1u>, cpp_dec_float<50u>, int_<3> >' CC -c -std=c++11 t.cc # Oracle Studio 12.4 C++ compilation "t.cc", line 17: Error: Ambiguous partial specialization for canonical_imp<Val, Backend, Tag><number<cpp_dec_float<50, int, void>, 1>, cpp_dec_float<50, int, void>, int_<3>>, canonical_imp<Val, Backend, int_<3>> and canonical_imp<number<B, 1>, Backend, Tag>. t.cc ================================== template< bool B> struct enable_if_c{ typedef bool type; }; template< int N > struct int_{}; enum expression_template_option {et_on=1}; template <class Backend, expression_template_option ExpressionTemplates> class number; template <class Val, class Backend, class Tag> struct canonical_imp { typedef int type; }; template <class B,class Backend,class Tag> struct canonical_imp<number<B,et_on>,Backend,Tag> { typedef B type; }; template <class Val, class Backend> struct canonical_imp<Val,Backend,int_<3>>{ typedef Val type; }; template <class Val, class Backend> struct canonical { typedef typename canonical_imp<Val, Backend, int_<3>>::type type; }; template<typename From, typename To> struct is_restricted_conversion { typedef bool type; }; template <class Backend, expression_template_option ExpressionTemplates> class number { public: number() {} template <class V> number(const V& v,typename enable_if_c<!is_restricted_conversion<typename canonical<V,Backend>::type,Backend>::value>::type * =0){} }; template <unsigned Digits10, class ExponentType = int, class Allocator = void> class cpp_dec_float; template <unsigned Digits10, class ExponentType, class Allocator> class cpp_dec_float { public: cpp_dec_float() {} }; template <class RealType> void instantiate(RealType) {} typedef number<cpp_dec_float<50>, et_on> test_type; void foo() { instantiate(test_type()); } =============================== Any suggestions how to fix this? Thanks, Sergey

2 2

[githelp] Pulling to arbitrary branch?
by Rene Rivera 29 Dec '14

29 Dec '14

I have a pull request against one branch (master). But I want to pull it into a different branch (develop). Is that possible? And if so, how? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 5

[filesystem] ISO TS 18822, Technical Specification - File System
by Beman Dawes 29 Dec '14

29 Dec '14

The filesystem TS has been unanimously approved by ISO. 32 countries voted. The document has been forwarded to the ISO Central Secretariat for publication. The current working draft, which is technically the same as the TS but may have editorial corrections, is available at http://cplusplus.github.io/filesystem-ts/working-draft.html Many thanks to all the Boost folks who contributed so much to the Boost library that became the ISO TS! The C++ standards committee Filesystem Study Group will continue to operate, and will issue further TSes as further proposals dictate, and will continue to publish a working paper as issues for the TS are corrected. Happy Boost New Year, --Beman

1 0

What does "install dist-lib" in the inspect Jamfile do?
by Peter Dimov 29 Dec '14

29 Dec '14

I'm looking at Boost.Inspect's Jamfile as an example of how installation is done, and it has: install dist-bin : inspect : <install-type>EXE <location>../../../dist/bin : release ; install dist-lib : inspect : <install-type>LIB <location>../../../dist/lib : release ; The first one I get; it copies inspect.exe to dist/bin. But what does the second one do?

2 1

[core] A better boost::swap
by Antony Polukhin 29 Dec '14

29 Dec '14

Hi all, Ion Gaztañaga implemented a very good swap that used move emulation when possible and has all the features of boost::swap: http://www.boost.org/doc/libs/develop/boost/move/adl_move_swap.hpp I've tried to change default implementation of ::boost::swap to #include <boost/move/adl_move_swap.hpp> namespace boost { template<class T1, class T2> BOOST_GPU_ENABLED void swap(T1& left, T2& right) { ::boost::adl_move_swap(left, right); } } All the tests of the Boost.Swap passed. Ion's solution looks better than existing boost::swap. Are there any reasons not to change the existing implementation of Boost.Swap to Ion's version? -- Best regards, Antony Polukhin

7 9

Dependency Report (was RE: [core] A better boost::swap)
by Fletcher, John P 28 Dec '14

28 Dec '14

________________________________________ >From: Boost [boost-bounces(a)lists.boost.org] on behalf of Peter Dimov [lists(a)pdimov.com] >Sent: 27 December 2014 21:21 >To: boost(a)lists.boost.org >Subject: Re: [boost] [core] A better boost::swap >Andrzej Krzemienski wrote: ... >> http://www.pdimov.com/tmp/report-d5ca5be/module-levels.html >I've generated a new report at >http://www.pdimov.com/tmp/report-b1adfee/module-levels.html That is very interesting and helpful. Is there a location where it can be referenced? Thanks John

2 2

Interactive metaprogramming shells
by Abel Sinkovics 28 Dec '14

28 Dec '14

Hi, I've built interactive shells for preprocessor and template metaprogramming. I've been using them for development and debugging of metaprograms and I think Boost developers could also find them useful. You can type in (metaprogramming) expressions which get evaluated and the result is displayed immediately. For example you can type boost::mpl::push_front<boost::mpl::vector<int, char>, double>::type and you get boost_::mpl::vector<double, int, char> as the result (the boost_ namespace is used because there are some tricks there to make the output more readable). As an example for the preprocessor shell you can type BOOST_PP_REPEAT(3, foo BOOST_PP_TUPLE_EAT(3), ~) and you get foo foo foo as the result. The tools are based on the Boost.Wave library and Clang. You can get them here: Preshell for preprocessor: https://github.com/sabel83/preshell Metashell for template metaprograms: https://github.com/sabel83/metashell You can also try them from your browser here: http://abel.web.elte.hu/shell Feedback is welcome. Regards, Ábel

6 16

Re: [boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014
by Kyle Lutz 28 Dec '14

28 Dec '14

On Fri, Dec 19, 2014 at 1:07 PM, Thomas M <firespot71(a)gmail.com> wrote: > Dear all, > >> Review of the Compute library starts today > > Having spent the last 3 years on a larger-scale C++ project utilizing OpenCL > as main computing engine, without doubt a C++ GPGPU library is worthwhile. > My evaluation was based on studying the full docs, tutorial examples, > creating own (simple) applications, and inspecting selected implementation > details. Thanks for the review! I've addressed your comments in-line below: > I liked most the portable STL-like algorithms; combined with fairly > straightforward on-the-fly specifications of kernel functions (including > lambda expression support) GPGPU utilization becomes much more accessible > for every-day C++ programs. The design of this library part is rather clean > and aligns well with the C++ standard customs. I have checked a handful of > function interfaces and they correspond to the C++ STL variants. > > However I have also encountered a number of issues, of which I consider most > severe the overall library's design/aim: > > Khronos Group already provides (since years) a C++ bindings API itself > (https://www.khronos.org/registry/cl/specs/opencl-cplusplus-1.2.pdf) > Frankly the Khronos API is not an example of a clean, modern C++, but it > provides very fine-grained operations control (which can be crucial for > effective GPGPU performance), is developed (althouth a bit lagged) with > OpenCL itself, and covered in every elaborate OpenCL textbook. It is thus > IMHO the current de-facto C++ OpenCL wrapper standard. The proposed boost > library's parts core & utility (heavy in total!) seem to do just the same > interface-wise, yet lack some important features e.g. detailed control flow > (blocking / event setting), image classes, or deviate in subtle signature > details making it really difficult to grasp which does exactly what / > behaves differently. A boost library should not start from scratch but > integrate with and extend the Khronos API, both at C and C++ bindings level > (e.g. providing the STL-like algorithms to them in straightforward to use > manners). Programmers can thus rely on established practices (personally I > wouldn't switch away from the Khronos C++ API as main underlying workhorse!) > yet benefit from the extended functionality provided by the boost library. Can you give examples of where the OpenCL wrapper types in Boost.Compute are lacking? I am aware of the issue with image classes. While they do exist in Boost.Compute, their APIs are just not documented yet (though there are quite a few examples/tests which demonstrate their usage). I'll work on this. One particular issue that makes me hesitant is the lack of OpenCL 2.0 support in the "official" C++ bindings. The OpenCL 2.0 specification was released over a year ago (November 2013). The first public OpenCL 2.0 implementation was released by Intel three months ago (September 2014, followed closely by an AMD implementation). Boost.Compute had OpenCL 2.0 support implemented a week later. As of today (over a year since the specification was released), there is still no support for OpenCL 2.0 in the Khronos C++ OpenCL wrapper. I don't think it would be prudent to restrict Boost.Compute to a subset of the OpenCL API merely because of shortcomings in the "official" C++ wrapper. Other issues include lack of support for move-semantics (as well as various other C++11 features) and differing object sizes for wrapped types versus the OpenCL C API types (e.g. "sizeof(cl::Device) != sizeof(cl_device_id)" which prevents the ability to pass arrays of wrapped object types directly to C APIs). Overall I think implementing our own wrapper directly based on the C API reduces overall complexity (no workarounds for bugs/shortcomings in the C++ wrapper layer), allows us to fix bugs and issue updates quickly, and provides a more consistent and, IMHO, better API for OpenCL. Also, as they both just wrap the underlying OpenCL C API, interoperating between Boost.Compute wrapper types and the Khronos C++ wrapper types is trivial. If there are specific issues with the wrappers in Boost.Compute please submit a bug report [1]. > On the other hand to those rather new to OpenCL a simplified, less > error-prone design would be beneficial; equally this can raise the > productivity of everyone. The current design/implementation follows the > typical OpenCL execution model incl. some of its caveats (see tutorial > "Transforming Data"): explicitly copying input data to the device, executing > kernel(s), and then copying the output back to the host. Frequently however > the whole emphasis is on the kernel invocation (run an algorithm on the > data), rendering the copying an implementation detail that's "done because > it must be done" but otherwise makes code longer and comprises an error > source if forgotten. I have put much consideration into this and ultimately I don't feel it is right for the data-copying to be made implicit and hidden away from the user. I prefer the API which makes the memory copying operations and the host-device synchronization points explicit. These "under-the-hood" copy operations can be major sources of under-performing GPU-based applications and I don't think insulating the programmer from them makes the situation better. In any case, there is a simplified, high-level API available in Boost.Compute which allows kernels to directly operate on host memory. See the mapped_view class [2]. > I hence wonder if the following overall design would be more appropriate > (this is by no means a request to doing it this way, I just try to bring in > alternative perspectives): > > 1) build on top the Khronos C / C++ bindings API, i.e. use that as base > instead of the own core + utilities parts > 2) offering a high-level interface for algorithm execution that exposes > users to as little OpenCL internals as possible while giving the algorithms > lots of flexibility > 3) offering a high-level interface that auto-connects STL-containers with > OpenCL memory objects, implemented based on standard C++ / Khronos API > classes. > 4) offering a high-level interface that applies the algorithms directly to > objects of the Khronos C / C++ API. > > > The first point is rather obvious. To me the proposed library parts core + > utility appear as just another C++ wrapper, and unless this is done in > extremely (!!!) well manner (i.e. offering every functionality the Khronos > API does, yet making it clean from scratch, aligning it with Standard C++, > extending it by essential features etc., ensuring a rock-solid quality > control for reliability etc.; I'd set the bar really high here) I see no > reason to do it. If people are forced to use the proposed library core > wrapper just to gain access to the other functionality (and there is good > other functionality in there !) then I think there is a serious risk that a > considerable number of people simply turn away altogether. Well I would question the premise that the Khronos C++ wrapper is done in an "extremely well manner" and has "rock-solid quality" ;-). Could you let me know what parts of the core wrapper API fail to meet your bar for quality? > With respect to the second point I suppose something like that is doable: > > // BEGIN > > compute::gpgpu_engine gpgpuEngine; // default initialization links it to a > default device etc. > > // create vector, fill with data - ordinary C++ > std::vector<float> vec(10000); > std::generate(vec.begin(), vec.end(), rand); > > compute::transform(vec.begin(), > vec.end(), > vec.begin(), > compute::sqrt<float>(), > gpgpuEngine); > > std::cout << vec[0]; // results are already on the host > > // END > > So an instance of gpgpu_engine (or whatever name) gets setup once and can, > if needed, become customized for its behaviour (devices used, execution > policies etc.). This engine can then internally (hidden to the user, like a > std::vector manages it's memory) manage buffers, and when transform now gets > invoked it: > -) copies the data to one of its buffers (create one if none available) > -) run the kernel > -) copies the data to the host side container (keep buffer for reuse later) > > This would bring several advantages: > -) the code becomes very similar to ordinary C++ code -> short-handed, less > error-prone > -) buffers can be recycled among multiple algorithm calls (e.g. the engine > can cache a small number of buffers immediately available for future calls) > -) more efficient OpenCL runtime utilization (performance) because the whole > operation sequence has been abstracted: e.g. the input copy operation can be > enqueued in a non-blocking fashion, so the data transfer to the device and > the boost.compute kernel preparation can occur concurrently; equally while > the kernel runs the copy-back-to-host command can already become enqueued. > -) gpgpu_engine can encapsulate a number of policies that control its > behaviour (providing sensible default-configurations but allowing > fine-grained control if desired), e.g.: error handling (e.g. throwing > exception vs. setting some plain-odd OpenCL error codes); device to execute > on (if multiple available); copying back to the host in non-blocking manner > (like copy_async); to allow the selection of a 'smart' execution path (for > example if the input data do not warrant the overhead of a GPU call [e.g. if > they are too small or do not well fit GPU computation problems] defer the > call a plain STL-algorithm call or use OpenCL's built-in native C++ calling > threading functionality); etc. It would be beneficial if those options can > become temporarily overwritten (something like the boost::ios_..._saver > classes come to mind). > > > With respect to the third point I am thinking of something along the lines > of: > > template <class T, ... policies etc for both std::vector and cl::Buffer> > class vector_buffer > { > > private: > std::vector<T,...> vec; > cl::Buffer buf; > }; > > the class ensures that the std::vector and the buffer are automatically > synchronized whenever changes must become transparent (i.e. access). > Obviously this requires some thought if get functions grant access to the > plain std::vector / cl_mem/cl::Buffer; however for the present > implementation I also don't see what would stop me from hijacking a cl_mem > from a compute::vector and modify the buffer arbitrarily outside the > compute::vector class. These are definitely ideas I've thought about and these kinds of tools could all be built upon the current API. I've played around with basically a "kernel functor" abstraction which provides a class with the regular C++ "operator()(Args...)" function which stores internally an OpenCL kernel along with a command queue and any buffers it needs. This would then provide a simple, pure C++ interface for executing functions on the GPU that looks just like a normal C++ function call. I'd be very interested in pursing this more. > For 4) I am thinking of overloads for the algorithm to +- directly accept > Khronos C / C++ objects. Some really light-weight adapters adding e.g. > required type + size data could do the trick. This is fairly trivial. I have a patch in the works which would allow the Khronos C++ types to be passed anywhere that Boost.Compute wrapper types are used to make this all virtually transparent to the user. > In general I'd find it useful that all of a host object, a device object and > something linking a host with a device object can be an input / output of an > algorithm, and the implementation takes care of automatic data transfer. So > if the input refers to a host object the implementation automatically copies > the data to the device, if the output is a host object it also automatically > copies the result to it etc. See my response above, I'm not a huge fan of these automatic data transfer abstractions. However, I could be in favor of offering this functionality in a higher-level API. > A final but probably very important design consideration: > I wonder if boost needs a OpenCL-computing library, or a general > parallelization library. Presently the GPGPU world is already split too much > between CUDA and OpenCL as main players (hardware vendors doing their parts > ...), and technology is really rapidly moving (APUs etc.). > As Hartmut has already pointed out one approach could be to use the current > proposal as foundation for a parallelization implementation: cut it down to > the essentials of that and hide as much OpenCL implementation details as > possible. > A completely different approach could be to try coming up with a unifying > parallelization framework that supports multiple backends (OpenCL, CUDA, > others). Obviously this would be a tremendous amount of work (and getting > that API right is probably extremely difficult - the last thing we'd need is > just another restricted API causing more splitting) but in the long run > could be the more rewarding solution. I think developing a unifying parallel framework which can intelligently dispatch algorithms to multiple back-ends is outside the scope of Boost.Compute (and seemingly much more in the remit of the proposed C++ Parallelism TS). I think OpenCL is more than sufficient for running code efficiently across a variety of parallel hardware including GPUs, multi-core CPUs, FPGAs and various other accelerators which is why I chose it to build Boost.Compute on top of (along with it being cross-platform and an open-standard). > Implementation details: > > I have checked the implementation only briefly, mostly only when questions > arose for a few functions. Overall it looks ok and organized, yet I have > encountered some issues. > > 1) type safety [major issue - must be fixed before acceptance]: > Type safety is not a strength of OpenCL, and this is reflected at parts in > the implementation when it fails to add a proper conversion/protection > layer. Using compute::reduce it was embarrassingly easy to produce rubbish > results through the following code (modifying the provided tutorial code) : > > // BEGIN > > compute::device device = compute::system::default_device(); > compute::context context(device); > compute::command_queue queue(context, device); > > // generate random data on the host - type is float > std::vector<float> host_vector(10000); > std::generate(host_vector.begin(), host_vector.end(), rand); > > // create a vector on the device > compute::vector<float> device_vector(host_vector.size(), context); > > // transfer data from the host to the device > compute::copy(host_vector.begin(), host_vector.end(), device_vector.begin(), > queue); > > double reduction_result = 0.0; // result is of type double > compute::reduce(device_vector.begin(), device_vector.end(), > &reduction_result, queue); > std::cout << "result: " << reduction_result<< std::endl; > > // END > > The input data is of type float while the result shall be stored in a > double. This fails miserably under the current implementation because after > the reduction has completed the final value stored in device memory gets > copied merely byte-wise to the target variable (using a plain type-ignorant > clEnqueueReadBuffer), reading simply the 4 bytes from a float into an 8 byte > double (4/8 on my PC machine). I suppose reversing types (double as input, > float as output) will be even more spectacular because 4 superfluous bytes > simply overwrite the stack. > > The same affects a plain compute::copy, for example if above the > device_vector is of type double: > > // BEGIN > > // generate random data on the host - type is float > std::vector<float> host_vector(10000); > std::generate(host_vector.begin(), host_vector.end(), rand); > > // create a vector on the device - type is double > compute::vector<double> device_vector(host_vector.size(), context); > > // transfer data from the host to the device > compute::copy(host_vector.begin(), host_vector.end(), device_vector.begin(), > queue); > > // END > > it equally makes pang because the data are just copied byte-wise. > > The library must provide a strict type-safety for all algorithms / data > structures, where (in order of preference that comes to mind): > a) convert properly to target type if possible (above surely applicable) > b) issue compile-time error if conversions not possible > c) last fallback: throw a proper exception at runtime Thanks for providing these tests cases. I'll work on improving type-checking and error-reporting. If possible, could you submit these as bug reports to the issue tracker [1]? > 2) when inspecting the code flow in above copy operation I missed a debug > mode check that for a copy operation the output range can hold that many > elements; something like a safe iterator returned by device_vector.begin() > -> a good implementation should throw an organized error instead of just > overwriting memory. This is a very good idea. I'll work on adding more assertions to verify these sorts of pre-conditions for the algorithms. > 3) for float/double input containers compute::accumulate falls back to a > plain serial reduction, making element-wise additions (which is really slow > on a GPU). This is because can_accumulate_with_reduce returns false as it is > not defined for integral types. Is there a technical reason why it cannot > work for floating types? How many algorithms are affected by a possible > fallback to a plain serial execution order? Because floating-point addition is not associative. Doing this would lead to accumulate() producing different results on the device versus the host. If the user is willing to trade performance for accuracy, they can call the reduce() algorithm directly. However, I don't think Boost.Compute should make this call universally and thus it is left up to the user to decide. I think this is documented in the accumulate() function, I'll look into making it more clear. > 4) for types not supported under both OpenCL and C++ (e.g. long double, > bool, half) more specific error messages would be useful. Noted, I'll work on producing better error messages for unsupported types/operations. > Note: above are listed only issues which I have encountered during my few > trials; there's no claim whatsoever for complete coverage > > > Performance: > > I have not really tested performance so I cannot say much on it. > At times I spotted what appears as unnecessary OpenCL runtime overhead (e.g. > blocking commands, resetting kernel arguments upon each invocation) but I am > not familiar enough with the implementation to judge if this really just > redundant. If you find any unnecessary blocking/synchronization please report it to the bug tracker [1] and we'll get it fixed. > Invoking the OpenCL compiler always takes considerable time for any OpenCL > program. The library compiles kernels on demand when encountered to execute; > while this is technically reasonable I am not sure in how far it is clear to > everyone (foremost end-users of programs) that e.g. a simply accumulate of > 100 ints may take several seconds to execute in total on first invocation > simply because the kernel compilation takes that time. I guess this > considerable penalty also somewhat discourages from using the library to > create a number of kernels on the fly. True, the run-time compilation model provided by OpenCL does have some associated overhead. There a few techniques in Boost.Compute which help mitigate this. The first is a run-time program cache which keeps built versions of commonly used kernels ready so that the compilation cost is only payed once per application run (see the program_cache class [3]). The other is support for offline-caching of program binaries. This is enabled by defining "BOOST_COMPUTE_USE_OFFLINE_CACHE" and causes Boost.Compute to cache binaries for programs so that they are only compiled once the very first time they are run on the system. I'll work on documenting the compilation-overhead issues as well as the caching functionality better. > I would find it very useful if smart algorithms dispatch the algorithm to a > plain C++ algorithm if it's really predictable that a GPU execution will > just waste time (I have elaborated on this above). It's fairly trivial to > have data/algorithm combinations that are better not executed on the GPU, > being able to rely on some auto-mechanism would relief programmers. I disagree, I think the call on whether to execute the algorithm on the host or on an accelerator (with its associated overhead) should be left up to the user (or potentially a higher-level API built on top of Boost.Compute). While I agree that this would a useful feature, I just don't think Boost.Compute is the right place for that logic to live. > Answers to reviewer questions: > > 1. What is your evaluation of the design? > > See comments above > > > 2. What is your evaluation of the implementation? > > See comments above > > > 3. Documentation: > > Overall I find the documentation well written and structured. As minor > issues at times it could be more explicit / elaborate (e.g. for > compute::vector a short description is provided, but for several other > containers there is none; what are the accepted types for predicates in the > algorithms etc.). Will do. > The installation page misses that (on Windows) the OpenCL headers must be > explicitly included (it leaves the impression that the library would do it > on it's own). Hmm, the Boost.Compute headers do "#include <CL/cl.h>" where it is required. Does this not work correctly for you? If possible, could you report a bug for this with a bit more information? > The performance page should include more details with respect to overhead > and specifically "unintuitive" ones such as kernel compilation time. > Recommendations can be given when a problem is / is not suitable for GPU > execution. It is unclear if the provided measurements refer to float or > double; measurements for both should be provided. Will do. > 4. Overall usefulness of the library > > I find the portable STL-ish algorithms (+ their supplements) useful. With > respect to the core + utilities parts I think unnecessary competition with > existent wrappers is introduced. > > > 5. Did you try to use the library? > > I used MSVC 12 and had no problems installing it and running a few little > programs. > > > 6. How much effort did you put into your evaluation? > > I read the documentation, ran tutorial code and created a few example > programs on my own (I did not run any of the pre-packaged examples). When > questions arose I took close looks at the implementation (thus I focused > more on in-depth analyses of selected components instead of testing overall > into breadth). > > > 7. Are you knowledgeable about the problem domain? > > I consider myself knowledgeable of the problem domain. > > > 8. The core question: Do you think the library should be accepted as a Boost > library? > > Generally speaking yes but I recommend a major revision before acceptance is > reconsidered. My greatest concern revolves around the overall design aim. I > don't like the idea of competing with the Khronos API for general wrapping; > I'd prefer a more light-weight library with the STL-ish algorithms (or other > things) at the core, adding to what is already out there. The library needs > to find its own niche, minimizing overlap and elaborating on it's > novelty/strengths. The implementation must become more robust, presently it > is ways too trivial to break things. Thanks again for the review! There are lots of good ideas raised here. Let me know if you have any other feedback or if I can explain anything further/more clearly. -kyle [1] https://github.com/kylelutz/compute/issues [2] http://kylelutz.github.io/compute/boost/compute/mapped_view.html [3] http://kylelutz.github.io/compute/boost/compute/program_cache.html

7 16

[block_ptr] Region Based Memory Managment
by Phil Bouchard 27 Dec '14

27 Dec '14

Greetings Boost, I was talking to Filip Pizlo from the Webkit community and he pointed out that block_ptr is what we call a Region Based Memory Manager: http://en.wikipedia.org/wiki/Region-based_memory_management If we consider the worse case scenario, the sets (regions) can be unified to create a really big set. So to make block_ptr hybrid we could add a "garbage collection layer" to detect cycles inside a set that is not yet destructed. This function could be called explicitly whenever some memory usage quota is reached. It's very easy to implement. There is no other way to efficiently manage memory. Regards, -Phil

1 2

[test] Applying outstanding pull requests to develop and schedule merge of develop to master
by Jamie Allsop 26 Dec '14

26 Dec '14

Some time ago (more than 2 years) I submitted a set of four complimentary patches for Boost.Test of which one was partially applied. The tickets are: * Test Units (Cases and Suites) in Boost.Test do not capture __FILE__ and __LINE__ at declaration point making it impossible to provide source file linking using external test management tools https://svn.boost.org/trac/boost/ticket/7410 (modified patch applied) * Boost.Test, since boost 1.48 is using the deprecated Boost.Timer class - it should be updated to use the new class https://svn.boost.org/trac/boost/ticket/7397 https://github.com/boostorg/test/pull/15 * Detailed test status is not available in the Boost.Test log (status, assertions, passed) and so live test case status cannot be tracked https://svn.boost.org/trac/boost/ticket/7417 https://github.com/boostorg/test/pull/16 * Support multiple calls to framework::init() allowing wrappers to support running tests using test tools in full systems https://svn.boost.org/trac/boost/ticket/7419 https://github.com/boostorg/test/pull/17 I've updated and resubmitted patches on more than one occasion and also variously created patches against (the now) develop and master so I can actually apply them for myself for each new boost version. Now, the reason for my post is two-fold. First - I'd like to see these patches applied. They cause no user impacts and simply (a) fix broken functionality and (b) *significantly* improve the usefulness of Boost.Test. I am more than happy to help with maintaining Boost.Test since we rely on it heavily and I believe, on the whole it is a good library. Second - it is about time we formulated a schedule for merging develop into master for Boost.Test. Otherwise all the patches in the world are simply pointless. The patches I've submitted, like others will never see the light of day even if they are applied because develop is very different than master and it looks like a merge may never happen. It should be noted that for my patches I have a completely different set that I apply to an actual Boost release because of the large differences between the two branches. To recap - it is time to start actively shepherding patches into Boost.Test develop, but more importantly, it is time we started looking at a schedule for merging Boost.Test develop to master. The longer it is left the worse the impact will be. A lot of good work has been done on develop - the longer it stays there the more people will move away from Boost.Test in their own code and it will only have relevance to Boost libraries themselves. Jamie

3 6

[Test] Command line option --list_content
by Andreas Noll 26 Dec '14

26 Dec '14

Hi everyone, Within our company we heavily use Boost.Test. We use Visual Studio and have written an Visual Studio extension to show all test suites and test cases of a given test executable. This allows our developers to run all tests or only parts of them. This is necessary because we have some lengthy running tests - one could say they are more integration tests than unit tests. What we have to do currently is patching the Boost.Test code to add a command line switch to output a test executable's contents to stdout. The output shows the hierarchy of test suites and test cases and is consumed by our Visual Studio extension. As I have recognized, our patch seems to cover the same functionality as the --list_content switch that already exists in the trunk version of Boost.Test. We would really appreciate that --list_content becomes part of the official boost releases to make our patch obsolete. My questions: 1. What are the reason(s) why-list_content is not (yet) added to the release? Is there any schedule for its release? 2. Is there any way how we can help with that issue? I'm new to the community but maybe there is something our team or me can do to get the feature released. Best regards, Andreas Noll

2 1

[compute] kernels as strings impairs readability and maintainability
by Mathias Gaunard 25 Dec '14

25 Dec '14

Hi, While reading through the code of Boost.Compute to see what it does and how it does it, I often found that the approach used by the library of putting all OpenCL kernels inside of strings was an annoying limitation and made it quite difficult to reason with them, much less debug or maintain them. This has a negative effect on the effort needed to contribute to the library. Has separate compilation been considered? Put the OpenCL code into .cl files, and let the build system do whatever is needed to transform them into a form that can be executed. This would also make it easier to eventually provide a CUDA backend.

7 12

[core] [addressof.hpp] [addressof_test2.cpp] ISO C++ says that these are ambiguous
by Sergey Sprogis 25 Dec '14

25 Dec '14

It looks like he following code fragment from boost/core/addressof.hpp (latest trunk version) violates ISO C++ overloading rules: template<class T> struct addressof_impl { static BOOST_FORCEINLINE T * f( T & v, long ) { return reinterpret_cast<T*>( &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); } static BOOST_FORCEINLINE T * f( T * v, int ) { return v; } }; As a result, libs/core/test/addressof_test2.cpp fails to compile with Oracle Studio 12.4 C++ compiler while gcc-4.8.2 produces just warning here. It's easy to reproduce that behavior of both compilers with 26 lines test case listed below: gcc -c t.cc t.cc:7:33: warning: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: [enabled by default] return addressof_impl<T>::f(v,0); ^ CC -c t.cc "t.cc", line 7: Error: Overloading ambiguity between "static addressof_impl<convertible2>::f(convertible2&, long)" and "static addressof_impl<convertible2>::f(convertible2*, int)". t.cc ==================================== template<class T> struct addressof_impl{ static T *f(T &v,long){} static T *f(T *v,int){} }; template<class T> T *addressof(T &v){ return addressof_impl<T>::f(v,0); } template<class T> void scalar_test(T* =0){ T *px=new T(); T &x =*px; (addressof(x)==px)? 1 : 0; } class convertible{ public: convertible(int=0){} }; class convertible2{ public: convertible2(int=0){} operator convertible2 *()const{ return 0; } }; void foo(){ scalar_test<convertible>(); scalar_test<convertible2>(); } ============================== It would be nice if boost/core/addressof.hpp file will be changed somehow to fit the proper ISO C++ requirements. Sergey

3 2

[compute] Some questions
by Andrey Semashev 23 Dec '14

23 Dec '14

Hi, I have no experience with OpenCL or GPU computing in general, so bear with me if my questions sound silly. I have a few questions regarding Boost.Compute: 1. When you define a kernel (e.g. with the BOOST_COMPUTE_FUNCTION macro), is this kernel supposed to be in C? Can it reference global (namespace scope) objects and other functions? Other kernels? 2. When is the kernel compiled and uploaded to the device? Is it possible to cache and reuse the compiled kernel? 3. Why is the library not thread-safe by default? I'd say, we're long past single-threaded systems now, and having to always define the config macro is a nuisance. 4. Is it possible to upload the data to process to the device's local memroy from a user-provided buffer, without copying it to boost::compute::vector? Same for downloading. What I'd like to do is move some of data processing to the GPU while the rest is performed on the CPU (possibly with other libraries), and avoid excessive copying. 5. Is it possible to pass buffers in the device-local memory between different processes (on the CPU) without downloading/uploading data to/from the CPU memory? 6. Is it possible to discover device capabilities? E.g. the amount of local memory (total/used/free), execution units, vendor and device name? Thanks.

3 4

[compute] Review period extended till December 30 + sum up
by Antony Polukhin 23 Dec '14

23 Dec '14

Hi, Review period of Compute library extended till December 30. Some notes and answers to them that were pointed out during review so far: * Some of the algorithms could be tuned for a specific hardware - Library author is working on a auto-tuning solution and improves existing algos * Why OpenCL C API used instead of C++ API? - C++ API had issues, C API allows a bit more control. No C++ API for OpenCL 2.0 * API is not N4105 compatible, library is not N*** compatible - This could be easily fixed by a library that will use Compute as a backend * Some of the algorithms return futures while other work with command queues - This is because of the OpenCL design + async chains/futures would be probably added later * Not all the types of the Khronos API are supported - A few types are not documented yet, there's a patch in the works which would allow the Khronos C++ types to be passed into Compute algorithms * A few type related errors could be detected at compile time - This will be fixed, more asserts would be added to runtime only checkable places. Report issues to the tracker https://github.com/kylelutz/compute/issues * On small data sets CPU algorithm would work faster than a GPGPU. How about implicitly dispatching algo on CPU in those cases? - The call on whether to execute the algorithm should be left up to the user. While library author agrees that this would be a useful feature, he just don't think Compute is the right place for that logic. * How about providing way to do chains of async operations - This is a big task that will be solved some day. * How about providing Boost.ASIO like error handling via throw and error_code - Implementing an approach like ASIO's wouldn't be that difficult. Thanks to all the reviewers for spending their time and providing useful comments so far! -- Best regards, Antony Polukhin

1 0

[compute] Define user functions using lambda expressions
by Asbjørn 22 Dec '14

22 Dec '14

Hi, I'm probably missing something obvious, but how would I go about making a custom function using a lambda expression? Say I want to declare some function "sqr" which returns "_1 * _1", and then use this in a transform() lambda expression, ie transform(..., 2.0 * sqr(_1) - 3.0 * _1 + 5.0, ...); to evaluate 2x^2 - 3x + 5. If I try to use BOOST_COMPUTE_FUNCTION() I can't use the resulting function in a lambda expression it seems. Cheers - Asbjørn

2 2

[compute] some comments
by Mathias Gaunard 22 Dec '14

22 Dec '14

Hi, I do not know if I'll be doing a full review, but I have some comments from having skimmed through the code and documentation. From a quick glance, from all the algorithms that are supported, quite a few are not easy to implement with the OpenCL programming model efficiently. I think the documentation should say more about the implementation strategies of each algorithm, its complexity and how much it is parallelized.

2 1

[icl] insert_iterator and elements
by Jeff Flinn 22 Dec '14

22 Dec '14

interval_set has overloaded insert methods for both intervals and elements. Is there a reason there insert iterator lacks this ability. The line in the code below *itr = 4; fails to compile. This could be made to compile by: - adding an implicit constructor 'interval( const element& )' for the underlying (discrete) intervals, initializing to [element, element+1), or [element, element]. - adding an overloaded operator=( const element& ) - adding an element_insert_iterator class I've encountered 2 domains now where I need to construct an interval_set<int> from a range of ints. The most natural ways to accomplish this (for me) are: boost::copy( ints, inserter(int_interval_set) ); or boost::copy_range<int_interval_set>( ints ); Of course I can transform the incoming ints, but this seems a common enough usage pattern for the library to provide. Especially since the lack of this facility is asymmetric to the insert overloads of interval_set. #include <iostream> #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS #include <boost/icl/interval_set.hpp> #include <boost/range/algorithm/copy.hpp> int main() { typedef boost::icl::interval_set<int> IdSet; typedef IdSet::interval_type IdInterval; IdSet ids; ids.insert(3); boost::icl::insert_iterator<IdSet> itr(ids, ids.end()); *itr = IdInterval(1,2); //*itr = 4; //compile error no viable operator = boost::copy(ids, std::ostream_iterator<IdInterval>(std::cout)); std::cout << "\n"; return 0; }

1 0

[compute] review
by Pavan Yalamanchili 22 Dec '14

22 Dec '14

*Design and Implementation* The library provides an STL-like library for OpenCL devices. Although there are other libraries offering similar behavior, Boost.Compute is the most complete and the most generalized. The directory structure is well organized and easy to dig through to understand the implementation or debug an issue. Others have pointed out the existence of the OpenCL C++ wrapper and the fact that Compute library does not use it. Here are a few reasons why I think the author was *right* in his design decisions. - The C++ wrapper begins to look similar to the original OpenCL C interface once you start using it in a generalized fashion. - cl.hpp is monolithic (single file 12k+ LOC) and is not modular enough to only include the parts that you need. - Compute and cl.hpp have two different goals. The biggest selling point of Compute is the set of algorithms it supports not its C++ wrapper around OpenCL. Having said that, I think the Compute library might be better off with an additional interface that accepts the OpenCL-C++ wrapped objects. *Documentation* The documentation is comprehensive and the API is documented well. There are a few improvements that can be done. For example, the reference is at the bottom of the TOC and is hard to see immediately. The API reference in the TOC can also be expanded out a bit more to show the general categories of algorithms that are supported. *Potential Usefulness* It is fairly easy to transition from applications using vector algorithms in STL to Compute. The wide availability of OpenCL devices makes the library useful to a large user base. *Domain Knowledge* I am a developer of the ArrayFire library[1]. I am the lead engineer of a company that specializes in this domain. I consider myself to be fairly knowledgeable in this domain. *Experience with the library* ArrayFire depends on Boost.Compute for a few algorithms in our OpenCL backend. We explicitly and implicitly (via ArrayFire) test Boost.Compute on a variety of hardware / compilers / operating systems. Compilers and Operating systems we use: - gcc 4.8, 4.9 on various Linux distributions - clang 3.4 on OSX - Visual Studio 2013 on Windows. We have found some bugs through our usage that have been mostly resolved by the author or by patches sent by us. *Conclusion* The experience overall has been fairly positive. But there are certainly *some* rough edges that need resolving. An issue that will plague any OpenCL library is the performance portability across various devices. It would be nice if the author can talk about how he plans to eventually address this issue. Overall, Boost.Compute will be a great addition to Boost. But before it is accepted the following issues need to be addressed. - The tests need to be a bit more comprehensive. - Due to the general nature of OpenCL, there needs to be a list of "officially supported" devices. - Make sure all the tests are passing on the supported devices. *Links* [1] https://github.com/arrayfire/arrayfire

2 1

A Google Summer of Code Proposal(Boost C++)
by Mudit Sharma 22 Dec '14

22 Dec '14

Respected Sir, I have been studying the Boost C++ libraries.I see that there isn't any library for game development in Boost C++. I propose a new library for game development for Boost C++ under which I propose to use the pygame library of python.Make a Boost C++ analogue for pygame library of python.. *I would like to know if this can be taken as a GSoC'15 project?* Thanking You Mudit Sharma (Student,Pursuing Electronics And Communication Engg. At Delhi Technological University,Delhi,INDIA)

5 5