On Mon, Feb 12, 2018 at 1:36 PM, Niall Douglas via Boost < boost@lists.boost.org> 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