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

Deprecate DoFTools::extract_boundary_dofs() with std::vector<bool> argument #11995

Merged
merged 8 commits into from
Apr 5, 2021

Conversation

bangerth
Copy link
Member

We have slowly been replacing these by functions using IndexSet instead, and indeed such a function already exists. The function here is not particularly widely used.

/rebuild

Copy link
Member

@masterleinad masterleinad left a comment

Choose a reason for hiding this comment

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

Looks good to me.

@masterleinad
Copy link
Member

/home/runner/work/dealii/dealii/examples/step-11/step-11.cc:150:36: error: ‘void dealii::DoFTools::extract_boundary_dofs(const dealii::DoFHandler<dim, spacedim>&, const dealii::ComponentMask&, std::vector<bool>&, const std::set<unsigned int>&) [with int dim = 2; int spacedim = 2]’ is deprecated [-Werror=deprecated-declarations]
     DoFTools::extract_boundary_dofs(dof_handler,
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
                                     ComponentMask(),
                                     ~~~~~~~~~~~~~~~~
                                     boundary_dofs);
                                     ~~~~~~~~~~~~~~
In file included from /home/runner/work/dealii/dealii/examples/step-11/step-11.cc:35:0:
/home/runner/work/dealii/dealii/include/deal.II/dofs/dof_tools.h:1459:3: note: declared here
   extract_boundary_dofs(const DoFHandler<dim, spacedim> &   dof_handler,
   ^~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors

@bangerth
Copy link
Member Author

Oh, I fix this place in #11996. Maybe I should just combine these two patches -- so done. Merging this patch is then also going to close #11996. That would also mean that if someone approved #11996, and since we already have two approvals for this PR here in its previous state, that the now combined patch here should be acceptable.

@jppelteret
Copy link
Member

I've removed the "Reviewed and ready to merge" label because I guess that you want to squash some of these commits, @bangerth?

While there also update the documentation of its replacement a bit.
…irectly.

We want to move away from these kinds of functions, so deprecate it and replace it by
a function that does the right thing instead.
@bangerth
Copy link
Member Author

bangerth commented Apr 5, 2021

I reduced the number of commits a bit, but what I have now is pretty self-contained in each commit.

Copy link
Member

@masterleinad masterleinad left a comment

Choose a reason for hiding this comment

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

Looks good to me.

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