Re: [boost] [system] virtual ~error_category

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

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

> > But as far as Boost.System goes, I think de-virtualising its destructor
> > is a major API break. I can see plenty of code out there in the wild
> > relying on that destructor firing when it's supposed to, and Boost
> > devirtualising it would equal a resource leak where there was none
> > before. That's as big as break as changing what `if(ec)` means (which
> > BTW is currently being deleted in `status_code` to force people to write
> > what they actually mean).
>
> It also occurs to me now that Charley mentioned to me once that some
> people instantiate custom categories carrying payload and hand them out
> one per error_code instance. It's a way of attaching payload to
> error_code. That use case definitely requires a virtual destructor to
> work right.
>

Yes, I did an implementation that effectively stored in the
(derived-)error_category all the state associated with a (circular-buffer)
of error-instances with instance-specific 'field-values'.  This worked.

However:

(1) It's kind of awkward, and I'm not sure I'm excited about this design
approach.  It was simply the only way I could figure out how to handle
stable error-field-values with the current <system_category> design (not
tied to 'error_code' value semantics).

(2) It might be "improper" to not have a virtual-dtor; But really, even if
I kept this current design I wouldn't care:  Because all log / filter /
pruning / sampling occurs as error instances are created-and-accessed (so
we probably don't really care about whether resources are deleted from an
explicit 'error_category::dtor()')

(3) The current design kinda demands the "singleton" behavior of
'error_category' (although I've found at least a couple work-arounds from
that which I believe to be conforming).  So, my guess is that people really
aren't expecting the 'error_category::dtor()' to actually do any "real"
work (since it probably only executes upon process-terminate, unless the
user is doing something really weird, which I admit is possible.)

So, I'm fine with dropping the 'virtual dtor' for 'error_category'.

--charley