Subject: Re: [boost] [outcome v2] ntkernel_category() custom error category appropriate for Outcome?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-21 11:55:00
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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk