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