From c7a4967d10fb9688f235baa8e57a1fb578f5387d Mon Sep 17 00:00:00 2001 From: Jay Berkenbilt Date: Thu, 8 Sep 2022 11:06:15 -0400 Subject: Change reset to disconnect and clarify comments I decided that it's actually fine to copy a direct object to another QPDF. Even if we eventually prevent a QPDFObject from having multiple parents, this could happen if an object is moved. --- libqpdf/QPDF.cc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'libqpdf/QPDF.cc') diff --git a/libqpdf/QPDF.cc b/libqpdf/QPDF.cc index c66cfd5a..1b1ee784 100644 --- a/libqpdf/QPDF.cc +++ b/libqpdf/QPDF.cc @@ -252,9 +252,11 @@ QPDF::~QPDF() // resolved indirect references by replacing them with an internal // object type representing that they have been destroyed. Note // that we can't break references like this at any time when the - // QPDF object is active. The call to reset also causes all + // QPDF object is active. The call to reset also causes all direct // QPDFObjectHandle objects that are reachable from this object to - // release their association with this QPDF. + // release their association with this QPDF. Direct objects are + // not destroyed since they can be moved to other QPDF objects + // safely. // At this point, obviously no one is still using the QPDF object, // but we'll explicitly clear the xref table anyway just to @@ -262,9 +264,7 @@ QPDF::~QPDF() this->m->xref_table.clear(); auto null_obj = QPDF_Null::create(); for (auto const& iter: this->m->obj_cache) { - iter.second.object->reset(); - // It would be better if reset() could call destroy(), but it - // can't -- see comments in QPDFValueProxy::reset(). + iter.second.object->disconnect(); iter.second.object->destroy(); } } -- cgit v1.2.3-54-g00ecf