On December 30, 2014 5:58:10 AM EST, "Gruenke,Matt"
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart
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.
Either way, I don't see how you avoid checking whether an error occurred after each operation.
You don't, but one is local to the last function call and the other is a global value.
And when you do detect an error, then you can certainly skip some work, but you're still stuck waiting for the non-failed operations to complete before you can destroy any of the datastructures they're using. And that would be much simpler with a good contingent of RAII-friendly constructs, like those we're discussing.
Okay
Therefore, I don't see the issue of exceptions vs. error codes (nor the mechanism of error code access) being relevant to the discussion of synchronization.
People were looking for ways to avoid exceptions. Whether that was to support embedded environments without exception support or to avoid exception overhead, I don't know.
The synchronization support needs to be there, no matter what. And it should be relatively unobtrusive and easy to use.
Sure
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.
By comparison with network programming (since you cited Boost.ASIO), GPU/OpenCL errors should be far less common. Therefore, error handling needn't be optimized for performance.
What about embedded programming environments without exception support?
BTW, the types of operations generating these errors typically involve communication with a device or at least a couple syscalls. So, the kind of ALU pipeline effects of conditional statements that you mention aren't relevant, here.
They still apply if the error checking is done on the host side. ___ Rob (Sent from my portable computation engine)