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
fix maybe-unused warning in grid_tools_dofhandler #16871
Conversation
tjhei
commented
Apr 7, 2024
std::array<unsigned int, GeometryInfo<dim>::vertices_per_face> | ||
face1_vertices, face2_vertices; | ||
face1_vertices{}, face2_vertices; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand why this patch fixes the warning, but I don't understand why this is the right thing to do. In the code below, down to line 2475, face1_vertices
and face2_vertices
seem to be written into in always the same places. So it's not clear to me why initializing only one of these but not the other is right.
But really what's unclear to me is why initialization with zero is right. Do we expect every element of the array to be written into? If so, perhaps initialization with an invalid value would be the right choice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume the diagnostics just pick up the loop iterating over face1_vertices
in the other function, but I don't know for sure.
I don't understand the code fully, but I now fill both with invalid data and check the content at the end. We'll see what happens.
6b3f89e
to
651a0c6
Compare
``` ./include/deal.II/grid/reference_cell.h:2799:22: warning: ‘face1_vertices.std::array<unsigned[763/12022] M_elems[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized] ./source/grid/grid_tools_dof_handlers.cc:2438:7: note: ‘face1_vertices.std::array<unsigned int, 1>::_M_elems[0]’ was declared here ```
651a0c6
to
1612211
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is better. I'm confounded by you choosing obj.end() == std::find(...)
over std::find(...) == std::end()
:-)