Clash Royale CLAN TAG#URR8PPP

Why is the first parameter of the std::error_code constructor fixed to an int

Since I've learned about std::error_code, I'm using it a lot and I love the minimalist and flexible design of this library. But I'm disturbed by one issue. What is the reason to define the constructor of std::error_code like this:

error_code( int ec, const error_category& ecat ) noexcept;


This prevents clients from using 64-bit error_codes in an environment where an int is compiled with 32-Bit (which is true for all Visual Studio compilers). Wouldn't it be far more flexible to use a type that can be adapted to the platform like std::size_t? Or, to provide the user with full control over the underlying integer type, to introduce a std::basic_error_code template class to get a behaviour similar to std::basic_string with its typedefs std::string and std::wstring:

std::size_t

std::basic_error_code

std::basic_string

std::string

std::wstring

namespace std

template<class IntT>
class basic_error_code

public:
basic_error_code(IntT ec, const error_category& cat)
: _Myec(ec)
, _Mycat(&cat)


...

private:
IntT _Myec;
const error_category *_Mycat;
;

using error_code = basic_error_code<int>;
// namespace std


Of course it would be necessary to add an additional conversion constructor for 64-bit error_codes to be able to work with std::error_code which is using 32-bit, but I see currently no problem to define one.

std::error_code

Update

I appreciate all your answers and of course, you are right in general; there is no need of so many error codes.

But let me give you two examples, where it would make sense nevertheless:

If you have an existing code from another system, which doesn't use std::error_code and this code uses 64-Bit values (maybe you don't want to use all of these codes but only a sup-range). You can easily convert this code into a std::error_code by defining your own category. If you have additionaly a #define list of all these codes, it is really just a little copy and paste, because you can use the #define macro names right in your enum.

If you want to use an | operation to combine different error_codes into one. It is possible and operates very well in combination with the std::error_code framework (I've already implemented such a system). In this case, you run really fast out of possibilities, if you can only use 32-Bit.
Well, before you complain about the uniqueness of an error_code, which is a combination of different error_codes; this is not really a problem, because you have error conditions, which can mask away the unwanted error_code part to fetch back the original error_code (the one, which you had, before you used the | operation)

I'm looking forward to hear further comments about this topic.

basic_error_code

std::error_code

1 Answer
1

std::error_code is designed to wrap/replace various existing error systems like errno and HRESULT which use 32-bit error codes (int in the case of errno and LONG for HRESULT).

std::error_code

errno

HRESULT

int

errno

LONG

HRESULT

I can't envisage a situation where you would need more than 4 billion (2^32) error codes in a single category. For example errno gets by with providing error codes for most of posix with around 130 error codes.

errno

Using a larger type would require more memory usage for no benefit.

error_category

error_code

ec

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.