Mention that a few places in the library actually do use the user_pointers.

git-svn-id: https://svn.dealii.org/trunk@9618 0785d39b-7218-0410-832d-ea1e28bc413d

diff --git a/deal.II/deal.II/include/grid/tria.h b/deal.II/deal.II/include/grid/tria.h
index a821fefcf78b3b1d3e15cb21daf54e12192ed5b1..06d891c6dd13d36f7c464e561a3cf18d84e3c1be 100644 (file)
--- a/deal.II/deal.II/include/grid/tria.h
+++ b/deal.II/deal.II/include/grid/tria.h
@@ -979,15 +979,20 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   It is recommended that a functions using the flags states so in its
  *   documentation.
  *
- *   There is another set of user data, namely a <tt>void *</tt>, for each
- *   line, quad, etc. You can access these user pointers through the
- *   functions <tt>user_pointer()</tt>, <tt>clear_user_pointer()</tt> and
- *   <tt>set_user_pointer(p)</tt> in the accessor classes. These pointers are
- *   neither used nor changed by the library and are @p NULL by
- *   default. Thus, their handling is the sole responsibility of the
- *   application program.  Especially, the pointers are not inherited
- *   to children upon refinement. Still, after a remeshing they are
- *   available on all cells, where they were set on the previous mesh.
+ *   There is another set of user data, namely a <tt>void *</tt>, for
+ *   each line, quad, etc. You can access these user pointers through
+ *   the functions <tt>user_pointer()</tt>,
+ *   <tt>clear_user_pointer()</tt> and <tt>set_user_pointer(p)</tt> in
+ *   the accessor classes. These pointers are not used nor changed in
+ *   many places of the library, and those classes and functions that
+ *   do use them should document this clearly; the most prominent user
+ *   of these pointers is the Solutiontransfer class.
+ *
+ *   The value of these user pointers is @p NULL by default. Note that
+ *   the pointers are not inherited to children upon
+ *   refinement. Still, after a remeshing they are available on all
+ *   cells, where they were set on the previous mesh (unless, of
+ *   course, overwritten by the SolutionTransfer class).
  *
  *   The usual warning about the missing type safety of @p void pointers are
  *   obviously in place here; responsibility for correctness of types etc
@@ -997,6 +1002,7 @@ struct TriaNumberCache<3> : public TriaNumberCache<2>
  *   which does no harm since the vertices have a unique and continuous number
  *   unlike the structured objects lines and quads. 
  *
+ *
  *   @sect3{Boundary approximation}
  *
  *   You can specify a boundary function for each boundary

diff --git a/deal.II/doc/news/c-5.0.html b/deal.II/doc/news/c-5.0.html
index 0845766976d060bd5653d03b61c2391824d77a95..88ad8e6883a6ed709cf7edfecad34fcaefef2413 100644 (file)
--- a/deal.II/doc/news/c-5.0.html
+++ b/deal.II/doc/news/c-5.0.html
@@ -326,6 +326,16 @@ inconvenience this causes.
 <h3>deal.II</h3>
 
 <ol>
+  <li> <p>
+       Fixed: The documentation of the <code
+       class="member">Triangulation</code> class mentioned that no
+       places in the library use or touch the user pointers. That is
+       wrong, the <code class="member">SolutionTransfer</code> class
+       actually does. This is now properly documented.
+       <br> 
+       (WB 2004/09/15)
+       </p>
+
   <li> <p>
        Fixed: The <code
        class="member">DerivativeApproximation::approximate_second_derivative</code>