-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Sebastian Schaetz Sent: Monday, December 22, 2014 11:16 To: boost@lists.boost.org Subject: Re: [boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014
Thomas M writes:
Isn't there a precedent here? If we look at MPI and Boost.MPI we have something similar. There is a standard C implementation and a crude (but official and established) C++ wrapper around that (that was removed in MPI3 btw). And as far as I know Boost.MPI builds on top the C implementation of MPI and just does a much better job than the official C++ wrapper.
To me, it seems more useful to focus on suitability of the solution (i.e. the proposed library) to a problem domain, rather than making legalistic arguments based on precedent. For instance, you could consider Boost.Thread and Boost.ASIO. They would've been useful as simple pthreads and sockets API wrappers, respectively. But they went further. Why? I'd like to think it's because this would've left out too many platforms with similar APIs, or with native APIs that offered better performance than going through a pthreads or sockets emulation layers. To this end, it seems to me an OpenCL-specific library for parallel computation leaves too many platforms out in the cold. While we could speculate about HSA and future acceleration APIs that would be omitted, there already exist multitudes of multicore and multiprocessor systems which don't support OpenCL but do support threading. In my opinion, this is no small point. 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.