Boost logo

Boost :

Subject: Re: [boost] Proposed SG14 <system_error2> ready for feedback
From: Bjorn Reese (breese_at_[hidden])
Date: 2018-03-03 12:56:46


On 02/28/18 23:10, Niall Douglas via Boost wrote:

> 7. `std::error_code` enforced its value to always be an `int`. This is
> problematic for coding systems which might use a `long` and implement
> coding namespaces within the extended number of bits, or for end users
> wishing to combine a code with a `void *` in order to transmit payload
> or additional context. As a result, `status_code` is templated to its
> domain, and the domain sets its type. A type erased edition of
> `status_code<D>` is available as `status_code<void>`, this is for
> obvious reasons non-copyable, non-movable and non-destructible.
>
> A more useful type erased edition is `status_code<erased<T>>`
> which is available if `D::value_type` is trivially copyable, `T` is an
> integral type, and `sizeof(T) >= sizeof(D::value_type)`. This lets you
> use `status_code<erased<T>>` in all your public interfaces without
> restrictions. As a pointer to the original category is retained, and
> trivially copyable types may be legally copied by `memcpy()`, type
> erased status codes work exactly as normal, except that publicly it does
> not advertise its type.

While I do see the need for providing extensions, I am not sure if
status_code<void> is useful given all its "non-" characteristics.
Can you elaborate on its use-cases?

I propose that the customizable status_code<D> is renamed to
basic_status_code<D>.

In keeping with the pre-established practices of std::error_code using
int, I furthermore suggest that status_code becomes a non-templated
alias for basic_status_code<int>.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk