// @sect3{Mesh generation}
// This is the function that produced the circular grid in the previous step-1
-// example program with fewer refinements steps. The sole difference is that it returns the grid it
-// produces via its argument.
+// example program with fewer refinements steps. The sole difference is that it
+// returns the grid it produces via its argument.
//
// The details of what the function does are explained in step-1. The only
// thing we would like to comment on is this:
for (unsigned int step=0; step<3; ++step)
{
- Triangulation<2>::active_cell_iterator cell = triangulation.begin_active();
- Triangulation<2>::active_cell_iterator endc = triangulation.end();
-
- for (; cell!=endc; ++cell)
+ for (auto cell: triangulation.active_cell_iterators())
for (unsigned int v=0;
v < GeometryInfo<2>::vertices_per_cell;
++v)
//
// The shortcuts, finally, are only defined to make the following loops a
// bit more readable. You will see them in many places in larger programs,
- // and `dofs_per_cell' and `n_q_points' are more or less by convention the
+ // and `dofs_per_cell` and `n_q_points` are more or less by convention the
// standard names for these purposes:
const unsigned int dofs_per_cell = fe.dofs_per_cell;
const unsigned int n_q_points = quadrature_formula.size();
// the type, types::global_dof_index, used here):
std::vector<types::global_dof_index> local_dof_indices (dofs_per_cell);
- // Now for the loop over all cells. We have seen before how this works, so
- // the following code should be familiar including the conventional names
- // for these variables:
- DoFHandler<2>::active_cell_iterator cell = dof_handler.begin_active();
- DoFHandler<2>::active_cell_iterator endc = dof_handler.end();
- for (; cell!=endc; ++cell)
+ // Now for the loop over all cells. We have seen before how this works for a
+ // triangulation. A DoFHandler has cell iterators that are exactly analogous
+ // to those of a Triangulation, but with extra information about the degrees
+ // of freedom for the finite element you're using. Looping over the active
+ // cells of a degree-of-freedom handler works the same as for a triangulation.
+ //
+ // Note that we declare the type of the cell as `const auto &` instead of
+ // `auto` this time around. In step 1, we were modifying the cells of the
+ // triangulation by flagging them with refinement indicators. Here we're only
+ // examining the cells without modifying them, so it's good practice to
+ // declare `cell` as `const` in order to enforce this invariant.
+ for (const auto &cell: dof_handler.active_cell_iterators())
{
- // @note As already mentioned in step-1, there is a more convenient way
- // of writing such loops if your compiler supports the C++11
- // standard. See @ref CPP11 "the deal.II C++11 page" to see
- // how this works.
- //
// We are now sitting on one cell, and we would like the values and
// gradients of the shape functions be computed, as well as the
// determinants of the Jacobian matrices of the mapping between
// boundary by different numbers and tell the interpolate_boundary_values
// function to only compute the boundary values on a certain part of the
// boundary (e.g. the clamped part, or the inflow boundary). By default, all
- // boundaries have the number `0', and since we have not changed that, this
- // is still so; therefore, if we give `0' as the desired portion of the
+ // boundaries have the number `0`, and since we have not changed that, this
+ // is still so; therefore, if we give `0` as the desired portion of the
// boundary, this means we get the whole boundary. If you have boundaries
// with kinds of boundaries, you have to number them differently. The
// function call below will then only determine boundary values for parts of
// dimensions, but a hexahedron in 3D. In fact, the
// <code>active_cell_iterator</code> data type is something different,
// depending on the dimension we are in, but to the outside world they look
- // alike and you will probably never see a difference although the classes
- // that this typedef stands for are in fact completely unrelated:
- typename DoFHandler<dim>::active_cell_iterator
- cell = dof_handler.begin_active(),
- endc = dof_handler.end();
-
- for (; cell!=endc; ++cell)
+ // alike and you will probably never see a difference. In any case, the real
+ // type is hidden by using `auto`:
+ for (const auto &cell: dof_handler.active_cell_iterators())
{
fe_values.reinit (cell);
cell_matrix = 0;