[MOAB-dev] r5241 - in MOAB/trunk/itaps: . imesh

[jvporter at wisc.edu]

Author: jvporter
Date: 2011-12-08 12:39:44 -0600 (Thu, 08 Dec 2011)
New Revision: 5241

Modified:
   MOAB/trunk/itaps/iBase.h
   MOAB/trunk/itaps/imesh/iMesh.h
   MOAB/trunk/itaps/imesh/iMesh_MOAB.cpp
Log:
Update spec


Modified: MOAB/trunk/itaps/iBase.h
===================================================================
--- MOAB/trunk/itaps/iBase.h	2011-12-08 18:37:56 UTC (rev 5240)
+++ MOAB/trunk/itaps/iBase.h	2011-12-08 18:39:44 UTC (rev 5241)
@@ -9,10 +9,10 @@
  * Technically speaking, there is not much practical value in patch digit
  * for an interface specification. A patch release is typically only used
  * for bug fix releases. Although it is rare, sometimes a bug fix
- * necessitates an API change. So, we define a patch digit for iMesh.
+ * necessitates an API change. So, we define a patch digit for iBase.
  *
  * Although each interface in ITAPS has been designed to support its own
- * uniqe version numbers, apart from other ITAPS interfaces, as currently
+ * unique version numbers, apart from other ITAPS interfaces, as currently
  * used, we require all ITAPS interfaces to use the same ITAPS-wide version
  * number derived from the version number defined by these three digits.
  ******************************************************************************/
@@ -114,7 +114,7 @@
     iBase_REGION,
         /**< A topological dimension 3 entity */
     iBase_ALL_TYPES,
-        /**< used only in queires to request information about all types */
+        /**< used only in queries to request information about all types */
     iBase_EntityType_MAX = iBase_ALL_TYPES
         /**< facilitates iteration over all values */
 };
@@ -409,6 +409,152 @@
  * Note that iMesh itself currently does not define any options. In order
  * to discover options a given implementation defines, users are directed
  * to the developers of the respective implementations.
+ *
+ * \page resilient Resilient and Non-Resilient Iterators
+ *
+ * A resilient iterator is one that can deal with modifications to the container
+ * it is iterating over.
+ *
+ * A common concern about an iterator is how it behaves when the container
+ * over which it is iterating is modified. For example, in STL, iterators
+ * for std::set<> and std::map<> and std::list<> containers are guaranteed
+ * to <em>work</em> in the presence of modifications to the associated
+ * containers with one exception; they don't handle the case when the
+ * container member the iterator is currently pointed at is deleted. However,
+ * iterators for std::vector<> are not guaranteed to work under any kinds of
+ * modification.
+ *
+ * In the ITAPS interfaces, a <em>resilient</em> iterator is one that makes
+ * certain guarantees (described below) about how it behaves when the
+ * container being iterated is modified. On the other hand, a
+ * <em>non-resilient</em> is one that does not make such guarantees.
+ *
+ * In all cases, the <em>container</em> associated with an iterator in the