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.
That's something I was considering for Boost.System (literally the same
thing, a random 64 bit ID). Unfortunately, the virtual destructor makes
error_category a non-literal type, so categories can't be constexpr
variables. Hence, my earlier inquiry about the switch to a protected
nonvirtual ~error_category.
status code domain has a trivial destructor, and thus is 100% constexpr
end to end of its lifetime.
You should be aware Peter that your input during the previous
discussions was unusually valuable in deciding the design of
. Sufficiently so that I previously have mentioned you by
name in the private discussions as having given particularly valuable
feedback. Thank you.
Something I've probably not mentioned to you before is that you called
the `filesystem::path` design right during its peer review. Your
proposed design was the correct one. The one which ended up being chosen
and is now to be standardised is inferior to your design.
AFIO chose your design for its path_view. It's considerably the better
for it.
BTW, I'm not sure if you or Boost is aware, but WG21 is busy making all
of the std::filesystem error_code APIs throwing as well as error code
returning i.e. they might fail either by error code, or also by throwing
an exception, and to date I have not seen a clear articulation of when
which will happen other than error_code being used for "file errors" and
exception throws for "non-file errors", whatever that means.
They expect to complete this "improvement" at Jacksonville by
retroactively modifying the C++ 17 standard via the defect process, as
apparently the original noexcept semantics is a defect. You can see more
at http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#3013,
keep reading down to see more madness.
I'll state now on the record that some parts of WG21 clearly most be
smoking something real good for such an action to make any sense. I know
that it was originally intended that Filesystem ought to throw in its
error code overloads around a decade ago, but ASIO's supremacy has
changed what the C++ user base expect when they see an error_code& API.
They expect that all failures will be indicated by said error_code&.
So should Filesystem, as indeed the C++ 17 standard said it would.
Because that's the widely understood convention now. Undoing that now,
when you could just set ec to
std::make_error_code(std::errc::not_enough_memory) or whatever is
backwards and retrograde in my opinion.
And besides: some stats from AFIO for ext4 on Linux on a 3.4Ghz Ivy
Bridge machine with a budget Crucial MX100 SSD:
create file: 6453 ns
enumerate file: 192 ns
open file read: 1133 ns
open file write: 1195 ns
delete file: 12338 ns
Those are *nano*seconds. A throw-catch cycle is at least 1000 ns.
What the f*ck are WG21 smoking on intentionally adding more exception
throws in here on Filesystem?
Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
