Re: Protected destructors

On Sep 28, 2024, at 13:23, Jonathan Vollebregt <jnv@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