On Sep 28, 2024, at 13:23, Jonathan Vollebregt <j...@jnvsor.net> wrote: > >> Okay. My point is that you cannot know (unless there are no circular >> dependencies) *when* a destructor is called by the engine; > > The benefit of non-public visibility isn't when it's called, but how many > times it's called. If you can declare your destructor non-public you can be > confident it'll only be called once per instance (By the engine) > > Or is there a scenario where the engine will call a destructor more than once > on the same instance? > >> Destructors should (IMHO) be public. Not necessarily because they can be >> called, but classes with destructors hint at underlying behavior when >> destructed. For performance, you might want to defer that by retaining a >> reference. If a class has a hidden destructor, you have to go read the code >> to find it. > > Wouldn't you have to read the code to see if it had a public destructor too?
I would argue that, semantically, destructors should be *private*. You should never need to know if a class has a destructor, and you should never call it manually. The engine should automatically handle calling parent destructors when necessary. If there really is some logic in the destructor that a user of a class might legitimately want to use, then that should be exposed in a separate method (with a more appropriate name, and an implementation that handles that it might be called more than once) and have the destructor call that method. -John
