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

Subject: Re: [boost] Proposed SG14 <system_error2> ready for feedback
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-03-02 15:32:56

> Not obvious to me: especially the templetized codes, and two kinds of type
> erasure. This part of the design is definitely more complicated than the
> original <system_error>. I would expect examples and some rationale.

Oh ok. Thanks for explaining.

> If you choose to describe <system_error2> as a diff from <system_error>, I
> would expect all relevant differences to be mentioned in the docs. For
> instance I can see you use `status_code_domain` rather than
> `error_category`. This looks like an improvement in clarity.

Previous feedback from Arthur suggested that.

> Also, how do
> you handle error code names without strings? Do i need to define my own
> string_ref?

The default string_ref implementation returns unmanaged static const
char strings. So if your strings are those, you need do nothing.

The posix_code domain implementation shows how to implement a reference
counted string retrieved dynamically from the system.

> Similarly, how did you fix the "duplicated globals" problem on Windows?

That's actually a problem on POSIX as well. All platforms are affected.
You cannot make header only libraries with custom error category which
work right on any platform.

It was fixed by making the category source a constexpr variable, and
each is given a 64 bit random unique id by its author from random.org.
If the ids match, the domains are considered equal.

Much of the time the compiler can therefore skip id comparison, as it
knows both sources are constexpr and it knows the unique id at
constexpr. But if push comes to shove, it can compare the ids, and it
doesn't matter if the singleton is not unique in the process.

> Also, there is this paragraph:
> 
> The relationship between std::error_code and std::error_condition is
> confusing to many users reading code based on <system_error>, specifically
> when is a comparison between codes *semantic* or *literal*? status_code
> makes all comparisons *semantic*, *always*. If you want a literal
> comparison, you can do one by hand by comparing domains and values
> directly.
> 
> I fail to see what you mean by "semantic comparison" and "literal
> comparison". Do they mean comparing error_code to error_category and
> comparing error_code to error_code respectively?

Correct. So, in error_category's case, semantic comparisons occur via
.equivalent() which is called when operator==() is done between an
error_code and error_condition. It's the same for status code domain,
there is an .equivalent() function. The difference is that there is no
such thing as error conditions, and operator==() always calls .equivalent().

We also don't provide ordering nor hashing for status code, as equality
testing is semantic. These ought to not be used in maps without a custom
comparison.

> Any information would be useful, but I think it is more basic things that
> are insufficiently described.
> For now, consider it a feedback on what a casual reader will not understand
> about <system_error2> .

I'm hesitant to write much in the way of docs until the design has been
empirically tested in AFIO. But it's basically a concrete implementation
of the possible improvements to error_code we discussed here a few weeks
back.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/