Re: [boost] Proposed SG14 <system_error2> ready for feedback

...

On all systems, there is a typedef `system_code` which is to the erased status code sufficiently large that you are guaranteed that all possible system error coding schemes can be safely erased into it. For POSIX, this is `status_code`, as `int` can hold all possible error codings. For Windows, this is `status_code>`, as `intptr_t` can hold any of a `DWORD`, a `LONG` and a `HRESULT`.

DWORD (aka uint32_t) can hold any of DWORD, LONG, and HRESULT.

Or use LONG (aka int32_t) if you want to retain signedness of LONGs, though I don't think any Win32 APIs require this.

In any case intptr_t is either larger than needed to preserve the value bits (in 64-bit applications) or smaller than needed to preserve the value and sign (in 32-bit applications), so this seems like an inappropriate choice.

Structure alignment would align any int to the pointer, so same space in any case. Two CPU registers.

(HRESULT is not a pointer type, despite most other H* types being derived from HANDLE. Yay for consistency.)

I did actually look that up before choosing it, and at the time found one of the platform configs was defining it to HANDLE. But I can't find that again now, so I must have been tired and confused. In private discussions with some on WG21, it is felt that status code needs to always be two CPU registers exactly. So I'll be bumping that to intptr_t on all platforms. It's also been requested that a new `error` type be created which refines status_code. `error` always represents a failed status_code, and nothing else. It cannot be empty, it cannot be success. Outcome will be using this new type `error` as its E type in its experimental form. You may be seeing a ton load more about this proposed `error` type during the coming year. It is very exciting. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/