summaryrefslogtreecommitdiff
path: root/src/context/cdhashmap.h
diff options
context:
space:
mode:
Diffstat (limited to 'src/context/cdhashmap.h')
-rw-r--r--src/context/cdhashmap.h158
1 files changed, 79 insertions, 79 deletions
diff --git a/src/context/cdhashmap.h b/src/context/cdhashmap.h
index 9a8ae925f..32b0cc8cc 100644
--- a/src/context/cdhashmap.h
+++ b/src/context/cdhashmap.h
@@ -1,82 +1,82 @@
-/********************* */
-/*! \file cdhashmap.h
- ** \verbatim
- ** Top contributors (to current version):
- ** Morgan Deters, Tim King, Dejan Jovanovic
- ** This file is part of the CVC4 project.
- ** Copyright (c) 2009-2021 by the authors listed in the file AUTHORS
- ** in the top-level source directory and their institutional affiliations.
- ** All rights reserved. See the file COPYING in the top-level source
- ** directory for licensing information.\endverbatim
- **
- ** \brief Context-dependent map class.
- **
- ** Context-dependent map class. Generic templated class for a map
- ** which must be saved and restored as contexts are pushed and
- ** popped. Requires that operator= be defined for the data class,
- ** and operator== for the key class. For key types that don't have a
- ** std::hash<>, you should provide an explicit HashFcn.
- **
- ** See also:
- ** CDInsertHashMap : An "insert-once" CD hash map.
- ** CDTrailHashMap : A lightweight CD hash map with poor iteration
- ** characteristics and some quirks in usage.
- **
- ** Internal documentation:
- **
- ** CDHashMap<> is something of a work in progress at present (26 May
- ** 2010), due to some recent discoveries of problems with its
- ** internal state. Here are some notes on the internal use of
- ** CDOhash_maps that may be useful in figuring out this mess:
- **
- ** So you have a CDHashMap<>.
- **
- ** You insert some (key,value) pairs. Each allocates a CDOhash_map<>
- ** and goes on a doubly-linked list headed by map.d_first and
- ** threaded via CDOhash_map.{d_prev,d_next}. CDOhash_maps are constructed
- ** with a NULL d_map pointer, but then immediately call
- ** makeCurrent() and set the d_map pointer back to the map. At
- ** context level 0, this doesn't lead to anything special. In
- ** higher context levels, this stores away a CDOhash_map with a NULL
- ** map pointer at level 0, and a non-NULL map pointer in the
- ** current context level. (Remember that for later.)
- **
- ** When a key is associated to a new value in a CDHashMap, its
- ** associated CDOhash_map calls makeCurrent(), then sets the new
- ** value. The save object is also a CDOhash_map (allocated in context
- ** memory).
- **
- ** Now, CDOhash_maps disappear in a variety of ways.
- **
- ** First, you might pop beyond a "modification of the value"
- ** scope level, requiring a re-association of the key to an old
- ** value. This is easy. CDOhash_map::restore() does the work, and
- ** the context memory of the save object is reclaimed as usual.
- **
- ** Second, you might pop beyond a "insert the key" scope level,
- ** requiring that the key be completely removed from the map and
- ** its CDOhash_map object memory freed. Here, the CDOhash_map is restored
- ** to a "NULL-map" state (see above), signaling it to remove
- ** itself from the map completely and put itself on a "trash
- ** list" for its scope.
- **
- ** Third, you might delete the cdhashmap(calling CDHashMap::~CDHashMap()).
- ** This first calls destroy(), as per ContextObj contract, but
- ** cdhashmapdoesn't save/restore itself, so that does nothing at the
- ** CDHashMap-level. Then, for each element in the map, it marks it as being
- ** "part of a complete map destruction", which essentially short-circuits
- ** CDOhash_map::restore() (see CDOhash_map::restore()), then deallocates
- ** it.
- **
- ** Fourth, you might clear() the CDHashMap. This does exactly the
- ** same as CDHashMap::~CDHashMap(), except that it doesn't call destroy()
- ** on itself.
- **
- ** ContextObj::deleteSelf() calls the CDOhash_map destructor, then
- ** frees the memory associated to the CDOhash_map.
- ** CDOhash_map::~CDOhash_map() calls destroy(), which restores as much as
- ** possible.
- **/
+/******************************************************************************
+ * Top contributors (to current version):
+ * Morgan Deters, Tim King, Dejan Jovanovic
+ *
+ * This file is part of the cvc5 project.
+ *
+ * Copyright (c) 2009-2021 by the authors listed in the file AUTHORS
+ * in the top-level source directory and their institutional affiliations.
+ * All rights reserved. See the file COPYING in the top-level source
+ * directory for licensing information.
+ * ****************************************************************************
+ *
+ * Context-dependent map class.
+ *
+ * Generic templated class for a map which must be saved and restored as
+ * contexts are pushed and popped. Requires that operator= be defined for the
+ * data class, and operator== for the key class. For key types that don't have
+ * a std::hash<>, you should provide an explicit HashFcn.
+ *
+ * See also:
+ * CDInsertHashMap : An "insert-once" CD hash map.
+ * CDTrailHashMap : A lightweight CD hash map with poor iteration
+ * characteristics and some quirks in usage.
+ *
+ * Internal documentation:
+ *
+ * CDHashMap<> is something of a work in progress at present (26 May
+ * 2010), due to some recent discoveries of problems with its
+ * internal state. Here are some notes on the internal use of
+ * CDOhash_maps that may be useful in figuring out this mess:
+ *
+ * So you have a CDHashMap<>.
+ *
+ * You insert some (key,value) pairs. Each allocates a CDOhash_map<>
+ * and goes on a doubly-linked list headed by map.d_first and
+ * threaded via CDOhash_map.{d_prev,d_next}. CDOhash_maps are constructed
+ * with a NULL d_map pointer, but then immediately call
+ * makeCurrent() and set the d_map pointer back to the map. At
+ * context level 0, this doesn't lead to anything special. In
+ * higher context levels, this stores away a CDOhash_map with a NULL
+ * map pointer at level 0, and a non-NULL map pointer in the
+ * current context level. (Remember that for later.)
+ *
+ * When a key is associated to a new value in a CDHashMap, its
+ * associated CDOhash_map calls makeCurrent(), then sets the new
+ * value. The save object is also a CDOhash_map (allocated in context
+ * memory).
+ *
+ * Now, CDOhash_maps disappear in a variety of ways.
+ *
+ * First, you might pop beyond a "modification of the value"
+ * scope level, requiring a re-association of the key to an old
+ * value. This is easy. CDOhash_map::restore() does the work, and
+ * the context memory of the save object is reclaimed as usual.
+ *
+ * Second, you might pop beyond a "insert the key" scope level,
+ * requiring that the key be completely removed from the map and
+ * its CDOhash_map object memory freed. Here, the CDOhash_map is restored
+ * to a "NULL-map" state (see above), signaling it to remove
+ * itself from the map completely and put itself on a "trash
+ * list" for its scope.
+ *
+ * Third, you might delete the cdhashmap(calling CDHashMap::~CDHashMap()).
+ * This first calls destroy(), as per ContextObj contract, but
+ * cdhashmapdoesn't save/restore itself, so that does nothing at the
+ * CDHashMap-level. Then, for each element in the map, it marks it as being
+ * "part of a complete map destruction", which essentially short-circuits
+ * CDOhash_map::restore() (see CDOhash_map::restore()), then deallocates
+ * it.
+ *
+ * Fourth, you might clear() the CDHashMap. This does exactly the
+ * same as CDHashMap::~CDHashMap(), except that it doesn't call destroy()
+ * on itself.
+ *
+ * ContextObj::deleteSelf() calls the CDOhash_map destructor, then
+ * frees the memory associated to the CDOhash_map.
+ * CDOhash_map::~CDOhash_map() calls destroy(), which restores as much as
+ * possible.
+ */
#include "cvc4_private.h"
generated by cgit on debian on lair
contact matthew@masot.net with questions or feedback