Re: [boost] [system] virtual ~error_category

Subject: Re: [boost] [system] virtual ~error_category
From: charleyb123 . (charleyb123_at_[hidden])
Date: 2018-02-12 20:42:59

On Mon, Feb 12, 2018 at 1:36 PM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> <snip>,
> I'm saying that there are people who make error categories via a
> factory, one per payload carried, and they attach them to a custom
> error_code whose destructor cleans up the bespoke error category.
>
> At least, this is the gist of what Charley told me. I could be wrong,
> memory could be faulty. I'm the wrong person to say on this. Maybe
> Charley will pipe in?
>

In my implementation, the 'error_code' is merely a "handle" to an
error-instance-with-field-values managed within the 'error_category'.

Specifically:  'int error_code::value()' is the "handle" within the
'error_category' that does all the resource management.

So, I don't need any behavior in 'error_code::dtor()', because I'm assuming
many arbitrary-lifespan copies (and the 'error_category' is robust in the
face of stale handle lookups).

But, I *could* see how one might do trickery in 'error_code::dtor' (that
just seems really expensive, since 'error_code' has value semantics, so I'd
assume people don't do that).  But, we're all really just experimenting
anyway.

I'd also loop in Chris on this. You might remember he said he's got
> custom categories retaining state back when he was arguing against
> fixing `if(ec)`.
>

I'm curious about any/all use cases where people put custom-state in the
derived 'error_category'.  I did that, but I'm not excited about it.

In my next design, all custom state goes elsewhere, except I *might*
consider the derived 'error_category' having a handle to custom state
(managed by somebody else).

--charley