[outcome v2] ntkernel_category() custom error category appropriate for Outcome?
I put together a custom `std::error_category` for NT kernel `NTSTATUS` error codes with error condition comparison support for both POSIX and Win32 error code spaces: https://github.com/ned14/ntkernel-error-category Question: Is this custom `std::error_category` so niche and unlikely to be useful to anybody that people would object to it being supplied in Outcome v2? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 21/07/2017 11:02, Niall Douglas via Boost wrote:
I put together a custom `std::error_category` for NT kernel `NTSTATUS` error codes with error condition comparison support for both POSIX and Win32 error code spaces:
I do like that this allows interpretation of NTSTATUS codes on non-Windows, although the chances of actually encountering one in that case seems rather slim (unless maybe CIFS APIs expose the raw server status code).
Question: Is this custom `std::error_category` so niche and unlikely to be useful to anybody that people would object to it being supplied in Outcome v2?
Isn't Outcome v2 header-only? It seems weird to add this to it in that case (because this prefers to build as a shared library). Much as it seems cumbersome to have such a small library be standalone, I think that might be the better choice, rather than changing a completely-header-only library into an only-kinda-header-only library. On the other hand, the exported-inline pattern *does* work (at least on Windows) to make real singletons between shared libraries even from header-only -- you just need to let the user pick one library to export the definition and ensure all consumers of that library import it. Presumably Linux/gcc has an equivalent?
On 21/07/2017 01:24, Gavin Lambert via Boost wrote:
On 21/07/2017 11:02, Niall Douglas via Boost wrote:
I put together a custom `std::error_category` for NT kernel `NTSTATUS` error codes with error condition comparison support for both POSIX and Win32 error code spaces:
I do like that this allows interpretation of NTSTATUS codes on non-Windows, although the chances of actually encountering one in that case seems rather slim (unless maybe CIFS APIs expose the raw server status code).
I was more thinking of log parsers actually. So the log can dump raw NTSTATUS codes on Windows, and portable code can parse that log on any platform. Still very niche though.
Question: Is this custom `std::error_category` so niche and unlikely to be useful to anybody that people would object to it being supplied in Outcome v2?
Isn't Outcome v2 header-only?
It seems weird to add this to it in that case (because this prefers to build as a shared library).
Fair point. The ntkernel-error-category DLL is several hundred Kb in size. It's definitely better as a shared library.
On the other hand, the exported-inline pattern *does* work (at least on Windows) to make real singletons between shared libraries even from header-only -- you just need to let the user pick one library to export the definition and ensure all consumers of that library import it. Presumably Linux/gcc has an equivalent?
It's tricky on both POSIX and Windows to get right, and most don't need to bother with perfect correctness. But that's the case for any C or C++ library that implements unique singletons, it's just unusual that you actually really do need to get it right else error condition comparisons will randomly fail. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (2)
-
Gavin Lambert -
Niall Douglas