Prev Up HomeNext

Approximate map between error code designs

Much of the design of Boost.System (which went on to become <system_error>) has been retained in proposed <system_error2>, so an approximate map between <system_error2> and <system_error> and Boost.System can be given:

C++ 17 <system_error>Boost.SystemProposed <system_error2>
std::errc boost::system::errc experimental::errc (almost identical)
std::error_category boost::system::error_category experimental::status_code_domain
std::generic_category boost::system::generic_category experimental::generic_code_domain
std::system_category boost::system::system_category One of:
  • experimental::posix_code_domain (POSIX systems)

  • experimental::win32_code_domain (Microsoft Windows)

  • experimental::nt_code_domain (Microsoft Windows)
std::error_condition boost::system::error_condition No equivalent (deliberately removed as hindsight proved it to be a design mistake leading to much confusing and hard to audit for correctness code)
std::error_code boost::system::error_code One of:
  • experimental::status_code<DomainType>

  • const experimental::status_code<void> &

  • experimental::status_code<erased<intptr_t>> (aliased to experimental::system_code)

  • experimental::errored_status_code<DomainType>

  • const experimental::errored_status_code<void> &

  • experimental::errored_status_code<erased<intptr_t>> (aliased to experimental::error)
std::system_error boost::system::system_error One of:
  • const experimental::status_error<void> &

  • experimental::status_error<DomainType>

As is obvious from the above, in <system_error2> one must be much more specific and accurate with respect to intent and specification and desired semantics than with <system_error>. Much ambiguity and incorrectness which flies silently in <system_error> will refuse to compile in <system_error2>.

Last revised: January 27, 2019 at 13:13:26 UTC


Prev Up HomeNext