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