Christopher Kohlhoff wrote:
Comments?
I'm concerned that, even though it may halve the number of functions, it actually increases the complexity overall.
Putting my standards-proposal-author hat on, it makes the specification of the behaviour of the single function more complex than the original non-throwing version.
The way to deal with that concern is to provide front matter that says: Unless otherwise specified, all functions taking an argument of error_code * do such-and-such. That way you don't have to say it for each function individually.
The increased number of code paths in the single function might also make it harder for the compiler to optimise the code. Even if you are only interested in using non-throwing functions, you could end up with the bookkeeping costs (space or time) associated with exceptions whether you like it or not.
Yes, that is a concern.
Another thought: from an implementation point of view, there's no way to ensure that the throw_on_error value is not written to accidentally (and it introduces a race condition if you do write to it). That increases the burden on the implementor. This cost potentially impacts on library users if they want to reuse the error_code facility in their own functions.
If we follow Guillaume's suggestion and use a pointer, that problem goes away. And I don't think we have much choice; comparing addresses across DLL boundaries has gotten me in trouble in the past so I think we have to avoid that.
While I appreciate the goal, I'm not convinced this is an improvement over the current method. I suppose my late night ramble above is really a round-about way of saying that the current error_code policy is better because it distinguishes between the two modes (throwing or non-throwing) at compile time, not run time.
Yes, and AFAIK there is no need to change behavior at runtime. Let me think about it a bit. You may be right. Thanks, --Beman