I could be way off base here, but I assumed the question related to the use of try/catch blocks, which are very expensive compared to unmanaged code. The divide by zero question is easy to answer, because unless one of the values is volatile, then it's more efficient to check the denominator before the division than put the division in a try/catch block. I suppose other examples are more complicated, but as far as I know for a library like this essentially nothing should use try/catch blocks, even if some code should have the capability to throw errors (which is a different matter entirely) -Hugh. On 3/23/07, John Maddock <john@johnmaddock.co.uk> wrote:
Martin Bonner wrote:
Why not throw an exception? Any overhead only occurs when an error has actually happened, not on every operation. Not quite. See below. Or even better:
if(error_condition) That is where the potential for additional overhead occurs. Now, how /serious/ it is, is an /entirely/ different matter. Obviously, it depends how much work it takes to calculate "error_condition", and how tight a loop we are in.
Absolutely: but unless you propose to have no error handling at all, the test is the same irrespective of whether we abort or throw or whatever, isn't it? What am I missing?
Cheers, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost