Skip to content
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

Another attempt to fix compile warning #15954

Merged
merged 2 commits into from Sep 7, 2023

Conversation

kronbichler
Copy link
Member

Second attempt to fix the gcc-10 warnings introduced by #15917 - it seems a if constexpr (dim == 0) return; does not make the compiler skip the rest, so I revert to the separate code that was present before 73ab8c4.

@kronbichler
Copy link
Member Author

For reference, the warnings are here: https://cdash.dealii.org/viewBuildError.php?type=1&buildid=1810

Comment on lines 609 to 610
constexpr int dim = 0;
AssertThrow(dim > 0, ExcNotImplemented());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why write it like this, and not just as follows?

Suggested change
constexpr int dim = 0;
AssertThrow(dim > 0, ExcNotImplemented());
AssertThrow(false, ExcNotImplemented());

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, I did this (and changed all other places in the file) in a separate commit.

Comment on lines -513 to -515
if constexpr (dim == 0)
return;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would the warning have gone away if you had put the rest into an else branch?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it would, but I do not like to increase of the indentation level that change many more lines. I also note that many other places are using the same technique with separate specializations for 0-d, see the changes I push in a moment for your other remark.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity: Do you dislike the change because you would not have liked to see the code written in that way to begin with, or because you don't like patches that change indentation? I believe that we should write patches that reflect the code we want, instead of so that they change the minimal number of lines. In other words, our code base should reflect our best effort to produce good and readable code, not reflect its history.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer if the code does not indent too much irrespective history, which is why I wrote the early return (I know you prefer the if() ... else ... form). Upon your suggestion, I then realized that the code has many of those template specialization, which I didn't want to touch all. Generally, if I'm given the alternative to indent more or to have separate functions, I would often go with separate functions if the code can be logically split like here. I would not be opposed to switch all occurrences in this class to if constexpr (dim > 0) {...}, because here the indentation is not worrisome. That said, I am certainly guilty of using if (...) return; in some of my code because it can lead to simpler control flow or less indentation when there are multiple conditions, but I also see the point in your preference, so I try to use it only in selected cases.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's a case of personal preference, and I'll leave it at your discretion :-)

@tamiko
Copy link
Member

tamiko commented Sep 2, 2023

@bangerth @kronbichler I will check into what gcc-10.4.1 is doing tomorrow. I have a suspicion that the only fix to this warning will be upgrading the compiler to 10.5.0.

@marcfehling marcfehling merged commit f6bdd85 into dealii:master Sep 7, 2023
15 checks passed
@kronbichler kronbichler deleted the fix_warning5 branch September 7, 2023 17:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants