Niall Douglas wrote:
It's very valid for a custom error code category to allocate some sort of internal state e.g. a hash table for looking up messages. This could be allocated statically, but it might also be allocated by the category instance on the basis that it was until now the same thing. This would not be freed on destruction if the `error_category` destructor were not virtual.
That's not true in the cases I can think of. Could you illustrate with code?
But as far as Boost.System goes, I think de-virtualising its destructor is a major API break.
It certainly is a potentially breaking change.
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.
Yes, it's better to make it protected, as Paul Groke observed. This way there'll be no silent failures.