-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C.128 Doesn't provide reasoning for rule exception with destructors #832
Comments
related #721 |
What is the procedure here? Should I propose rewording to that point or someone else is reviewing such issues and applying (or not) changes to the text? |
This is bothering me, too. I have also read discussions about it, but mostly only saw difference in opinions. Given that C.35 allows (and requires) a non-virtual protected destructor to be used, when I see a destructor declaration such as And what's even more important, if I switch the Before someone says that pure abstract classes (interfaces) should only have public virtual destructors, I would like to point again at C.35. Does destruction always have to be exposed in an interface?
Hopefully I make some sense, and this was not a waste of your time. Thanks. |
Fixed. |
Now the point states:
How is this "fixing" the issue? Still no reasoning is provided for skipping |
@adambadura I do agree. This destructor is intended to already be virtual, and if it happens it is not yet, this is an error. [1] The obvious reason could be that no base class function has the same name as the derived class destructor name. So no base class function with the derived class destructor name can be given a definition. Consequently no overriding of the definition of a base class fuction having the same name as the derived class destructor name can occur. But even if it seems logical, the definition of overriding has been modified to include the case of the destructor (13.3 - 6). Is it a defect according to these guidelines ? |
@MikeGitb Issue #721 raises the problem. The problem is said to be fixed in this issue by adding a repetition of the rule (918a569#diff-feb71ecadc563b52e66838adbd6b8e30). |
In the first place I thought that it is a good idea to enforce virtual/override/final for dtors. But since you pointed to C.35 I am in doubt and think that enforcing C.35 might be sufficient. |
@beinhaerter I would argue that the same can be asked about using "override" on any virtual function. It makes difference while I'm developing the class, while checking for consistency, and especially while and after refactoring it. I check for "protected" vs "public" on it, and I check whether it is virtual or not, and I consider that both of these features should be clearly expressed. Putting "override" on the destructor makes compiler catch the anti-example given in C.35. To me, even this is enough of a reason to use it. |
C.128 Virtual functions should specify exactly one of
virtual
,override
, orfinal
makes an exception for destructors:However no reasoning for this is provided.
I think it would be better to make it a separate paragraph, perhaps with some emphasis so that it clearly stands out as an exception to the general rule. And also provide there justification for such exception.
The text was updated successfully, but these errors were encountered: