From 932dce3afbd5295aecd44d4fb5617556b7ac9446 Mon Sep 17 00:00:00 2001 From: Daniel Arndt Date: Wed, 27 Jun 2018 15:10:26 +0200 Subject: [PATCH] Replace typedef by using in examples --- examples/step-12/step-12.cc | 6 ++--- examples/step-13/step-13.cc | 2 +- examples/step-14/step-14.cc | 16 ++++++------- examples/step-16/step-16.cc | 6 ++--- examples/step-22/doc/intro.dox | 4 ++-- examples/step-22/step-22.cc | 8 +++---- examples/step-3/doc/intro.dox | 44 ++++++++++++++++------------------ examples/step-32/step-32.cc | 16 ++++++------- examples/step-33/doc/intro.dox | 2 +- examples/step-35/step-35.cc | 4 ++-- examples/step-37/step-37.cc | 16 ++++++------- examples/step-39/step-39.cc | 6 ++--- examples/step-40/doc/intro.dox | 2 +- examples/step-50/step-50.cc | 9 ++++--- examples/step-55/step-55.cc | 5 ++-- examples/step-56/step-56.cc | 2 +- examples/step-59/step-59.cc | 21 ++++++++-------- 17 files changed, 82 insertions(+), 87 deletions(-) diff --git a/examples/step-12/step-12.cc b/examples/step-12/step-12.cc index 3f4b85c354..81f58761d5 100644 --- a/examples/step-12/step-12.cc +++ b/examples/step-12/step-12.cc @@ -189,10 +189,10 @@ namespace Step12 // all cells and much of the setup of operations will be done outside this // class, so all we have to provide are these three operations. They will // then work on intermediate objects for which first, we here define - // typedefs to the info objects handed to the local integration functions + // alias to the info objects handed to the local integration functions // in order to make our life easier below. - typedef MeshWorker::DoFInfo DoFInfo; - typedef MeshWorker::IntegrationInfo CellInfo; + using DoFInfo = MeshWorker::DoFInfo; + using CellInfo = MeshWorker::IntegrationInfo; // The following three functions are then the ones that get called inside // the generic loop over all cells and faces. They are the ones doing the diff --git a/examples/step-13/step-13.cc b/examples/step-13/step-13.cc index c8690cd25c..d65b252ece 100644 --- a/examples/step-13/step-13.cc +++ b/examples/step-13/step-13.cc @@ -1373,7 +1373,7 @@ namespace Step13 // Now solve the problem on the present grid, and run the evaluators // on it. The long type name of iterators into the list is a little - // annoying, but could be shortened by a typedef, if so desired. + // annoying, but could be shortened by an alias, if so desired. solver.solve_problem(); for (typename std::list< diff --git a/examples/step-14/step-14.cc b/examples/step-14/step-14.cc index 0a99b1f992..8d052eb7e3 100644 --- a/examples/step-14/step-14.cc +++ b/examples/step-14/step-14.cc @@ -1240,8 +1240,8 @@ namespace Step14 { // We need a class to denote the boundary values of the problem. In this // case, this is simple: it's the zero function, so don't even declare a - // class, just a typedef: - typedef Functions::ZeroFunction BoundaryValues; + // class, just an alias: + using BoundaryValues = Functions::ZeroFunction; // Second, a class that denotes the right hand side. Since they are // constant, just subclass the corresponding class of the library and be @@ -1760,8 +1760,8 @@ namespace Step14 // Then declare abbreviations for active cell iterators, to avoid that // we have to write this lengthy name over and over again: - typedef - typename DoFHandler::active_cell_iterator active_cell_iterator; + using active_cell_iterator = + typename DoFHandler::active_cell_iterator; // Next, declare a data type that we will us to store the contribution // of faces to the error estimator. The idea is that we can compute the @@ -1774,8 +1774,8 @@ namespace Step14 // cells a second time and grabbing the values from the map. // // The data type of this map is declared here: - typedef typename std::map::face_iterator, double> - FaceIntegrals; + using FaceIntegrals = + typename std::map::face_iterator, double>; // In the computation of the error estimates on cells and faces, we need // a number of helper objects, such as FEValues and @@ -2660,8 +2660,8 @@ namespace Step14 public: // First, we declare two abbreviations for simple use of the respective // data types: - typedef Evaluation::EvaluationBase Evaluator; - typedef std::list EvaluatorList; + using Evaluator = Evaluation::EvaluationBase; + using EvaluatorList = std::list; // Then we have the structure which declares all the parameters that may diff --git a/examples/step-16/step-16.cc b/examples/step-16/step-16.cc index 0b1394dd84..12a7064fd3 100644 --- a/examples/step-16/step-16.cc +++ b/examples/step-16/step-16.cc @@ -504,8 +504,8 @@ namespace Step16 // (such as CG or GMRES). The mg::SmootherRelaxation and // MGSmootherPrecondition classes provide support for these two kinds of // smoothers. Here, we opt for the application of a single SOR - // iteration. To this end, we define an appropriate typedef - // and then setup a smoother object. + // iteration. To this end, we define an appropriate alias and then setup a + // smoother object. // // The last step is to initialize the smoother object with our level // matrices and to set some smoothing parameters. The @@ -523,7 +523,7 @@ namespace Step16 // iteration (which requires a symmetric preconditioner) below, we need to // let the multilevel preconditioner make sure that we get a symmetric // operator even for nonsymmetric smoothers: - typedef PreconditionSOR> Smoother; + using Smoother = PreconditionSOR>; mg::SmootherRelaxation> mg_smoother; mg_smoother.initialize(mg_matrices); mg_smoother.set_steps(2); diff --git a/examples/step-22/doc/intro.dox b/examples/step-22/doc/intro.dox index ead7896cc7..5f05760c9a 100644 --- a/examples/step-22/doc/intro.dox +++ b/examples/step-22/doc/intro.dox @@ -554,13 +554,13 @@ struct InnerPreconditioner; template <> struct InnerPreconditioner<2> { - typedef SparseDirectUMFPACK type; + using type = SparseDirectUMFPACK; }; template <> struct InnerPreconditioner<3> { - typedef SparseILU type; + using type = SparseILU; }; @endcode diff --git a/examples/step-22/step-22.cc b/examples/step-22/step-22.cc index dd023a8c73..caa29fab3f 100644 --- a/examples/step-22/step-22.cc +++ b/examples/step-22/step-22.cc @@ -79,7 +79,7 @@ namespace Step22 // distinguish between them by the use of the spatial dimension as a // template parameter. See step-4 for details on templates. We are not going // to create any preconditioner object here, all we do is to create class - // that holds a local typedef determining the preconditioner class so we can + // that holds a local alias determining the preconditioner class so we can // write our program in a dimension-independent way. template struct InnerPreconditioner; @@ -88,14 +88,14 @@ namespace Step22 template <> struct InnerPreconditioner<2> { - typedef SparseDirectUMFPACK type; + using type = SparseDirectUMFPACK; }; // And the ILU preconditioning in 3D, called by SparseILU: template <> struct InnerPreconditioner<3> { - typedef SparseILU type; + using type = SparseILU; }; @@ -757,7 +757,7 @@ namespace Step22 // preconditioner for the velocity-velocity matrix, i.e., // block(0,0) in the system matrix. As mentioned above, this // depends on the spatial dimension. Since the two classes described by - // the InnerPreconditioner::type typedef have the same + // the InnerPreconditioner::type alias have the same // interface, we do not have to do anything different whether we want to // use a sparse direct solver or an ILU: std::cout << " Computing preconditioner..." << std::endl << std::flush; diff --git a/examples/step-3/doc/intro.dox b/examples/step-3/doc/intro.dox index f2b688a245..3ab7f6e42e 100644 --- a/examples/step-3/doc/intro.dox +++ b/examples/step-3/doc/intro.dox @@ -335,20 +335,19 @@ following tutorial programs.

A note on types

-deal.II defines a number of integral %types via typedefs in -namespace types. In particular, in this program you will see -types::global_dof_index in a couple of places: an integer type that is used to -denote the global index of a degree of freedom, i.e., the index of a -particular degree of freedom within the DoFHandler object that is defined on -top of a triangulation (as opposed to the index of a particular degree of -freedom within a particular cell). For the current program -(as well as almost all of the tutorial programs), you will have a few thousand -to maybe a few million unknowns globally (and, for $Q_1$ elements, you will -have 4 locally on each cell in 2d and 8 in 3d). Consequently, a data -type that allows to store sufficiently large numbers for global DoF indices is -unsigned int given that it allows to store numbers between 0 and -slightly more than 4 billion (on most systems, where integers are 32-bit). In -fact, this is what types::global_dof_index is. +deal.II defines a number of integral %types via alias in namespace types. In +particular, in this program you will see types::global_dof_index in a couple of +places: an integer type that is used to denote the global index of a +degree of freedom, i.e., the index of a particular degree of freedom within the +DoFHandler object that is defined on top of a triangulation (as opposed to the +index of a particular degree of freedom within a particular cell). For the +current program (as well as almost all of the tutorial programs), you will have +a few thousand to maybe a few million unknowns globally (and, for $Q_1$ +elements, you will have 4 locally on each cell in 2d and 8 in 3d). +Consequently, a data type that allows to store sufficiently large numbers for +global DoF indices is unsigned int given that it allows to store +numbers between 0 and slightly more than 4 billion (on most systems, where +integers are 32-bit). In fact, this is what types::global_dof_index is. So, why not just use unsigned int right away? deal.II used to do this until version 7.3. However, deal.II supports very large computations (via @@ -392,13 +391,12 @@ global indices of those degrees of freedom locally defined on the current cell" -- but variables that hold this information are universally named this way throughout the library. -@note types::global_dof_index is not the only type defined in this -namespace. Rather, there is a whole family, including types::subdomain_id, -types::boundary_id, and types::material_id. All of these are -typedefs for integer data types but, as explained above, they are -used throughout the library so that (i) the intent of a variable becomes more -easily discerned, and (ii) so that it becomes possible to change the actual -type to a larger one if necessary without having to go through the entire -library and figure out whether a particular use of unsigned int -corresponds to, say, a material indicator. +@note types::global_dof_index is not the only type defined in this namespace. +Rather, there is a whole family, including types::subdomain_id, +types::boundary_id, and types::material_id. All of these are alias for integer +data types but, as explained above, they are used throughout the library so that +(i) the intent of a variable becomes more easily discerned, and (ii) so that it +becomes possible to change the actual type to a larger one if necessary without +having to go through the entire library and figure out whether a particular use +of unsigned int corresponds to, say, a material indicator. diff --git a/examples/step-32/step-32.cc b/examples/step-32/step-32.cc index 5eec2c403c..73f6de2ff5 100644 --- a/examples/step-32/step-32.cc +++ b/examples/step-32/step-32.cc @@ -2308,8 +2308,8 @@ namespace Step32 const QGauss quadrature_formula(parameters.stokes_velocity_degree + 1); - typedef FilteredIterator::active_cell_iterator> - CellFilter; + using CellFilter = + FilteredIterator::active_cell_iterator>; WorkStream::run( CellFilter(IteratorFilters::LocallyOwnedCell(), @@ -2497,8 +2497,8 @@ namespace Step32 const QGauss quadrature_formula(parameters.stokes_velocity_degree + 1); - typedef FilteredIterator::active_cell_iterator> - CellFilter; + using CellFilter = + FilteredIterator::active_cell_iterator>; WorkStream::run( CellFilter(IteratorFilters::LocallyOwnedCell(), @@ -2610,8 +2610,8 @@ namespace Step32 const QGauss quadrature_formula(parameters.temperature_degree + 2); - typedef FilteredIterator::active_cell_iterator> - CellFilter; + using CellFilter = + FilteredIterator::active_cell_iterator>; WorkStream::run( CellFilter(IteratorFilters::LocallyOwnedCell(), @@ -2878,8 +2878,8 @@ namespace Step32 const double global_entropy_variation = get_entropy_variation(average_temperature); - typedef FilteredIterator::active_cell_iterator> - CellFilter; + using CellFilter = + FilteredIterator::active_cell_iterator>; WorkStream::run( CellFilter(IteratorFilters::LocallyOwnedCell(), diff --git a/examples/step-33/doc/intro.dox b/examples/step-33/doc/intro.dox index 13001144ca..f1b667af51 100644 --- a/examples/step-33/doc/intro.dox +++ b/examples/step-33/doc/intro.dox @@ -250,7 +250,7 @@ used: #include #include -typedef Sacado::Fad::DFad fad_double; +using fad_double = Sacado::Fad::DFad; main() { diff --git a/examples/step-35/step-35.cc b/examples/step-35/step-35.cc index 75ab69cfb3..91c4508559 100644 --- a/examples/step-35/step-35.cc +++ b/examples/step-35/step-35.cc @@ -872,8 +872,8 @@ namespace Step35 // and compressing it. It is important to notice here that the gradient // operator acts from the pressure space into the velocity space, so we have // to deal with two different finite element spaces. To keep the loops - // synchronized, we use the typedef's that we have defined - // before, namely PairedIterators and IteratorPair. + // synchronized, we use the alias that we have defined before, namely + // PairedIterators and IteratorPair. template void NavierStokesProjection::initialize_gradient_operator() { diff --git a/examples/step-37/step-37.cc b/examples/step-37/step-37.cc index 1c8e094427..aeed9f0c40 100644 --- a/examples/step-37/step-37.cc +++ b/examples/step-37/step-37.cc @@ -246,7 +246,7 @@ namespace Step37 Base> { public: - typedef number value_type; + using value_type = number; LaplaceOperator(); @@ -719,13 +719,13 @@ namespace Step37 DoFHandler dof_handler; ConstraintMatrix constraints; - typedef LaplaceOperator - SystemMatrixType; + using SystemMatrixType = + LaplaceOperator; SystemMatrixType system_matrix; MGConstrainedDoFs mg_constrained_dofs; - typedef LaplaceOperator LevelMatrixType; - MGLevelObject mg_matrices; + using LevelMatrixType = LaplaceOperator; + MGLevelObject mg_matrices; LinearAlgebra::distributed::Vector solution; LinearAlgebra::distributed::Vector system_rhs; @@ -1014,9 +1014,9 @@ namespace Step37 // methods. The former involves only local communication between neighbors // in the (coarse) mesh, whereas the latter requires global communication // over all processors. - typedef PreconditionChebyshev> - SmootherType; + using SmootherType = + PreconditionChebyshev>; mg::SmootherRelaxation> mg_smoother; diff --git a/examples/step-39/step-39.cc b/examples/step-39/step-39.cc index e16bee4156..910cd3856d 100644 --- a/examples/step-39/step-39.cc +++ b/examples/step-39/step-39.cc @@ -449,7 +449,7 @@ namespace Step39 class InteriorPenaltyProblem { public: - typedef MeshWorker::IntegrationInfo CellInfo; + using CellInfo = MeshWorker::IntegrationInfo; InteriorPenaltyProblem(const FiniteElement &fe); @@ -730,8 +730,8 @@ namespace Step39 // While transfer and coarse grid solver are pretty much generic, more // flexibility is offered for the smoother. First, we choose Gauss-Seidel // as our smoothing method. - GrowingVectorMemory> mem; - typedef PreconditionSOR> RELAXATION; + GrowingVectorMemory> mem; + using RELAXATION = PreconditionSOR>; mg::SmootherRelaxation> mg_smoother; RELAXATION::AdditionalData smoother_data(1.); mg_smoother.initialize(mg_matrix, smoother_data); diff --git a/examples/step-40/doc/intro.dox b/examples/step-40/doc/intro.dox index 6ed0e30e0e..366a350048 100644 --- a/examples/step-40/doc/intro.dox +++ b/examples/step-40/doc/intro.dox @@ -140,7 +140,7 @@ in the @ref distributed documentation module. to throw at it, and for as large a problem as you have the memory and patience to solve. However, there is a limit: the number of unknowns can not exceed the largest number that can be stored with an object of type -types::global_dof_index. By default, this is a typedef for unsigned +types::global_dof_index. By default, this is an alias for unsigned int, which on most machines today is a 32-bit integer, limiting you to some 4 billion (in reality, since this program uses PETSc, you will be limited to half that as PETSc uses signed integers). However, this can be changed diff --git a/examples/step-50/step-50.cc b/examples/step-50/step-50.cc index 2e2d9b7d17..4e5904b0ce 100644 --- a/examples/step-50/step-50.cc +++ b/examples/step-50/step-50.cc @@ -122,8 +122,8 @@ namespace Step50 FE_Q fe; DoFHandler mg_dof_handler; - typedef LA::MPI::SparseMatrix matrix_t; - typedef LA::MPI::Vector vector_t; + using matrix_t = LA::MPI::SparseMatrix; + using vector_t = LA::MPI::Vector; matrix_t system_matrix; @@ -726,8 +726,7 @@ namespace Step50 // SOR, Jacobi or Richardson method). The MGSmootherPrecondition // class provides support for this kind of smoother. Here, we opt // for the application of a single SOR iteration. To this end, we - // define an appropriate typedef and then setup a - // smoother object. + // define an appropriate alias and then setup a smoother object. // // The last step is to initialize the smoother object with our // level matrices and to set some smoothing parameters. The @@ -751,7 +750,7 @@ namespace Step50 // preconditioner make sure that we get a // symmetric operator even for nonsymmetric // smoothers: - typedef LA::MPI::PreconditionJacobi Smoother; + using Smoother = LA::MPI::PreconditionJacobi; MGSmootherPrecondition mg_smoother; mg_smoother.initialize(mg_matrices, Smoother::AdditionalData(0.5)); mg_smoother.set_steps(2); diff --git a/examples/step-55/step-55.cc b/examples/step-55/step-55.cc index 8af758535a..e417e727e5 100644 --- a/examples/step-55/step-55.cc +++ b/examples/step-55/step-55.cc @@ -625,9 +625,8 @@ namespace Step55 } // The InverseMatrix is used to solve for the mass matrix: - typedef LinearSolvers::InverseMatrix - mp_inverse_t; + using mp_inverse_t = LinearSolvers::InverseMatrix; const mp_inverse_t mp_inverse(preconditioner_matrix.block(1, 1), prec_S); // This constructs the block preconditioner based on the preconditioners diff --git a/examples/step-56/step-56.cc b/examples/step-56/step-56.cc index 8490615be9..f262c6182b 100644 --- a/examples/step-56/step-56.cc +++ b/examples/step-56/step-56.cc @@ -896,7 +896,7 @@ namespace Step56 MGCoarseGridHouseholder<> coarse_grid_solver; coarse_grid_solver.initialize(coarse_matrix); - typedef PreconditionSOR> Smoother; + using Smoother = PreconditionSOR>; mg::SmootherRelaxation> mg_smoother; mg_smoother.initialize(mg_matrices); mg_smoother.set_steps(2); diff --git a/examples/step-59/step-59.cc b/examples/step-59/step-59.cc index d31b000cc6..6e87415d00 100644 --- a/examples/step-59/step-59.cc +++ b/examples/step-59/step-59.cc @@ -175,7 +175,7 @@ namespace Step59 class LaplaceOperator : public Subscriptor { public: - typedef number value_type; + using value_type = number; LaplaceOperator() = default; @@ -235,7 +235,7 @@ namespace Step59 class PreconditionBlockJacobi { public: - typedef number value_type; + using value_type = number; void clear() { @@ -929,11 +929,11 @@ namespace Step59 FE_DGQHermite fe; DoFHandler dof_handler; - typedef LaplaceOperator SystemMatrixType; - SystemMatrixType system_matrix; + using SystemMatrixType = LaplaceOperator; + SystemMatrixType system_matrix; - typedef LaplaceOperator LevelMatrixType; - MGLevelObject mg_matrices; + using LevelMatrixType = LaplaceOperator; + MGLevelObject mg_matrices; LinearAlgebra::distributed::Vector solution; LinearAlgebra::distributed::Vector system_rhs; @@ -1220,11 +1220,10 @@ namespace Step59 << " s\n"; time.restart(); - typedef PreconditionChebyshev< - LevelMatrixType, - LinearAlgebra::distributed::Vector, - PreconditionBlockJacobi> - SmootherType; + using SmootherType = + PreconditionChebyshev, + PreconditionBlockJacobi>; mg::SmootherRelaxation> mg_smoother; -- 2.39.5