On December 29, 2014 6:49:35 PM EST, Kyle Lutz
On Mon, Dec 29, 2014 at 2:58 PM, Thomas M
wrote: Note that because your API can throw I consider exception effects to be of much greater concern than with the (implicitly non-throwing) Khronos API; and just enqueuing a couple of commands can make a proper, manual cleanup really easily non-trivial.
I have tried as much as possible to ensure that the library exception-safe (I surely hope you aren't assuming that I intentionally made the library non-exception-safe). If you do find any bugs related to exception handling please do submit them with a reproducible test-case to the issue tracker [1] and I will get them fixed as soon as possible. Also, in case you were unaware, you can always disable all exceptions in Boost.Compute by defining BOOST_NO_EXCEPTIONS.
BOOST_NO_EXCEPTIONS invokes a global handler to note a failure. That means after every library call, the user must check a global value to determine if there was an error. Overloading with a Boost.System error_code localizes error checking. (Asio does this, for example.) I consider that a superior way to avoid exception overhead. The question is whether exception overhead is a bottleneck in coding with this library's API. It is necessary to weigh the likelihood of errors against the costs of reporting and detecting them. Conditional logic to check for errors is not pipelining friendly, but throwing exceptions is terribly expensive. -- Rob (Sent from my portable computation engine)