Commit 93f176a2a035930aea76112e23e80661edc5fdd9

Authored by Jay Berkenbilt
Committed by GitHub
1 parent 8a3cdfd2

Documentation fix

Remove paragraph about traversal during destruction since this is still necessary with the
new implementation.
Showing 1 changed file with 3 additions and 8 deletions
manual/design.rst
@@ -398,7 +398,7 @@ Prior to qpdf 11, the functionality of the ``QPDFValue`` and @@ -398,7 +398,7 @@ Prior to qpdf 11, the functionality of the ``QPDFValue`` and
398 ``QPDFObject`` classes were contained in a single ``QPDFObject`` 398 ``QPDFObject`` classes were contained in a single ``QPDFObject``
399 class, which served the dual purpose of being the cache entry for 399 class, which served the dual purpose of being the cache entry for
400 ``QPDF`` and being the abstract base class for all the different PDF 400 ``QPDF`` and being the abstract base class for all the different PDF
401 -object types. The behavior was nearly the same, but there were a few 401 +object types. The behavior was nearly the same, but there were some
402 problems: 402 problems:
403 403
404 - While changes to a ``QPDFObjectHandle`` through mutation were 404 - While changes to a ``QPDFObjectHandle`` through mutation were
@@ -412,11 +412,6 @@ problems: @@ -412,11 +412,6 @@ problems:
412 replace its internal ``QPDFObject`` pointer. This added overhead to 412 replace its internal ``QPDFObject`` pointer. This added overhead to
413 every indirect object access even if no objects were ever changed. 413 every indirect object access even if no objects were ever changed.
414 414
415 -- When a ``QPDF`` object was destroyed, it was necessary to  
416 - recursively traverse the structure of every object in the file to  
417 - break any circular references. For complex files, this significantly  
418 - increased the cost of destroying ``QPDF`` objects.  
419 -  
420 - When a ``QPDF`` object was destroyed, any ``QPDFObjectHandle`` 415 - When a ``QPDF`` object was destroyed, any ``QPDFObjectHandle``
421 objects that referenced it would maintain a potentially invalid 416 objects that referenced it would maintain a potentially invalid
422 pointer as the owning ``QPDF``. In practice, this wasn't usually a 417 pointer as the owning ``QPDF``. In practice, this wasn't usually a
@@ -426,8 +421,8 @@ problems: @@ -426,8 +421,8 @@ problems:
426 software to do its own bookkeeping to ensure that an object's owner 421 software to do its own bookkeeping to ensure that an object's owner
427 was still valid. 422 was still valid.
428 423
429 -All of these problems were effectively solved by splitting  
430 -``QPDFObject`` into ``QPDFObject`` and ``QPDFValue``. 424 +These problems were solved by splitting ``QPDFObject`` into
  425 +``QPDFObject`` and ``QPDFValue``.
431 426
432 .. _casting: 427 .. _casting:
433 428