[LyX features/cleanup/updateMacros] Surely we do not need to clear objects that are about to be destroyed

Richard Kimberly Heck rikiheck at lyx.org
Mon Nov 9 21:08:13 UTC 2020


The branch, cleanup/updateMacros, has been updated.

- Log -----------------------------------------------------------------

commit efe55ba6a700ed9eec836d9bc23fd5756cfdcd47
Author: Richard Kimberly Heck <rikiheck at lyx.org>
Date:   Mon Nov 9 16:37:18 2020 -0500

    Surely we do not need to clear objects that are about to be destroyed

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 6665451..600d810 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -557,10 +557,6 @@ Buffer::~Buffer()
 			} else
 				cloned_buffers.erase(it);
 		}
-		// FIXME Do we really need to do this right before we delete d?
-		// clear references to children in macro tables
-		d->children_positions.clear();
-		d->position_to_children.clear();
 	} else {
 		// loop over children
 		for (auto const & p : d->children_positions) {
@@ -583,11 +579,6 @@ Buffer::~Buffer()
 			Alert::warning(_("Attempting to close changed document!"), msg);
 		}
 
-		// FIXME Do we really need to do this right before we delete d?
-		// clear references to children in macro tables
-		d->children_positions.clear();
-		d->position_to_children.clear();
-
 		if (!d->temppath.destroyDirectory()) {
 			LYXERR0(bformat(_("Could not remove the temporary directory %1$s"),
 				from_utf8(d->temppath.absFileName())));

commit 55aeff2a5decb515220b663705f4ee60c41755ea
Author: Richard Kimberly Heck <rikiheck at lyx.org>
Date:   Mon Nov 9 16:36:20 2020 -0500

    More comments and minor cleanup

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 7237737..6665451 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -213,18 +213,21 @@ public:
 	/// which maps the macro definition position to the scope and the MacroData.
 	NamePositionScopeMacroMap macros;
 
-	/// positions of child buffers in the buffer
+	/// Each child Buffer is listed in this map, together with where
+	/// it is included in this Buffer.
+	typedef map<Buffer const * const, DocIterator> BufferPositionMap;
+	BufferPositionMap children_positions;
+	/// We also have a map from the positions where Buffers are included
+	/// to those Buffers and their scope (whose point RKH does not yet 
+	/// understand).
+	// FIXME Surely one of these is enough?
 	struct ScopeBuffer {
-		ScopeBuffer() : buffer(nullptr) {}
+		ScopeBuffer() = default;
 		ScopeBuffer(DocIterator const & s, Buffer const * b)
 			: scope(s), buffer(b) {}
 		DocIterator scope;
 		Buffer const * buffer;
 	};
-	/// position of children buffers in this buffer
-	typedef map<Buffer const * const, DocIterator> BufferPositionMap;
-	BufferPositionMap children_positions;
-	/// map from children inclusion positions to their scope and their buffer
 	typedef map<DocIterator, ScopeBuffer> PositionScopeBufferMap;
 	PositionScopeBufferMap position_to_children;
 
@@ -5465,9 +5468,9 @@ bool Buffer::saveAs(FileName const & fn)
 
 void Buffer::checkChildBuffers()
 {
-	for (auto const & bit : d->children_positions) {
-		DocIterator dit = bit.second;
-		Buffer * cbuf = const_cast<Buffer *>(bit.first);
+	for (auto const & kid : d->children_positions) {
+		DocIterator const & dit = kid.second;
+		Buffer * cbuf = const_cast<Buffer *>(kid.first);
 		if (!cbuf || !theBufferList().isLoaded(cbuf))
 			continue;
 		Inset * inset = dit.nextInset();
@@ -5479,7 +5482,9 @@ void Buffer::checkChildBuffers()
 				onlyPath(absFileName())).absFileName();
 		if (oldloc == newloc)
 			continue;
-		// the location of the child file is incorrect.
+		// the location of the child file is incorrect. e.g., it
+		// had a relative path which does not now point to the correct
+		// file (after saveAs, usually).
 		cbuf->setParent(nullptr);
 		inset_inc->setChildBuffer(nullptr);
 	}

-----------------------------------------------------------------------

Summary of changes:
 src/Buffer.cpp |   34 +++++++++++++++-------------------
 1 files changed, 15 insertions(+), 19 deletions(-)


hooks/post-receive
-- 
Repository for new features


More information about the lyx-cvs mailing list