From 8292eaa8921bfdf8028b10581f981471b7a8f294 Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Tue, 22 Aug 2017 09:47:20 -0600 Subject: [PATCH] Fix a couple of more places in step-6. Specifically, in the documentation of the Subscriptor/SmartPointer thing. --- examples/step-6/step-6.cc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/examples/step-6/step-6.cc b/examples/step-6/step-6.cc index 6265835020..47103a2bbc 100644 --- a/examples/step-6/step-6.cc +++ b/examples/step-6/step-6.cc @@ -191,8 +191,8 @@ Step6::Step6 () // To be fair, such exceptions about still used objects are not particularly // popular among programmers using deal.II, since they only tell us that // something is wrong, namely that some other object is still using the object -// that is presently being destructed, but most of the time not who this user -// is. It is therefore often rather time-consuming to find out where the +// that is presently being destructed, but most of the time not who this using +// object is. It is therefore often rather time-consuming to find out where the // problem exactly is, although it is then usually straightforward to remedy // the situation. However, we believe that the effort to find invalid // references to objects that do no longer exist is less if the problem is @@ -203,12 +203,12 @@ Step6::Step6 () // Coming back to the present situation, if we did not write this destructor, // the compiler will generate code that triggers exactly the behavior sketched // above. The reason is that member variables of the Step6 class -// are destructed bottom-up (i.e. in reverse order of their declaration in the -// class), as always in C++. Thus, the finite element object will be -// destructed before the DoF handler object, since its declaration is below -// the one of the DoF handler. This triggers the situation above, and an -// exception will be raised when the fe object is -// destructed. What needs to be done is to tell the triangulation +// are destroyed bottom-up (i.e., in reverse order of their declaration in the +// class), as always in C++. Thus, the boundary object will be +// destroyed before the triangulation object, since its declaration is below +// the one of the triangulation. This triggers the situation above, and an +// exception will be raised when the boundary object is +// destroyed. What needs to be done is to tell the triangulation // object to release its lock to boundary. Of course, the // triangulation will only release its lock if it really does not // need the boundary any more. For this purpose, the -- 2.39.5