Commit 93f176a2a035930aea76112e23e80661edc5fdd9
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 |