Boost logo

Boost :

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

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).


Boost list run by bdawes at, gregod at, cpdaniel at, john at