On 29.1.2016. 14:27, Niall Douglas wrote:
On 28 Jan 2016 at 10:32, Michael Marcin wrote:
If you are going to handle the error in non-generic code very close to the caller, I contend there is no need to actually call make_error_code and wrap that enum into a std::error_code. The enum is typically 4 bytes, a std::error_code is usually 16.
Certainly many times it doesn't matter at all but there are also times where it would prevent me from having a good faith argument that this is a strict improvement over a more C-style error handling approach.
Unlike exception_ptr, error_code has no global memory effects and is elidable by the optimiser. Assuming there are no calls to extern functions between the return of an error_code and the handling of it, you will find your nominal 16 bytes reduced to a direct test of the state of errno/GetLastError which is of course no overhead at all.
And only if the function returning the error_code is inlined (or if the function has internal linkage and your compiler is 'very smart' and sees that the error_code is unused in all call sites and uses a custom calling convention that eliminates the error_code)...a good result<T, E> solution would produce optimal code even on ABI boundaries (e.g. a function returning a result<iterator_range, errno_t> exported from an x64 .so would pass the result in registers)... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman