#863 uses a single null object for nulls that were previously implicit. In
certain circumstances this shared null object gets destroyed (i.e changed
to a QPDF_Destroyed object) when a QPDF object is destroyed.
Modify the QPDF destructor so that null objects get disconnected from the
dying QPDF object but not destroyed to prevent this from happening.
An indirect object reference to 0, 0 is invalid. If it appears in the
file or is parsed from a string, the parser catches it. This check
would only be useful for someone explicitly calling getObject with 0,
0, and that would trigger an error during resolve().
QPDFValueProxy wasn't a good name for it. We decided the evil of
having the header file be named QPDFObject_private.hh was less than
the evil of having the class be named something other than what it
should have been named.
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.
When a QPDF is destroyed, changing indirect objects to direct nulls
makes them effectively disappear silently when they sneak into other
places. Instead, we should treat this as an error. Adding a destroyed
object type makes this possible.
This is in preparation for restoring a QPDFObject.hh to ease the
transition on qpdf_object_type_e.
This commit was created by
* Renaming QPDFObject.cc and QPDFObject.hh
* Replacing QPDFObject\b with QPDFValueProxy (where \b is word
boundary)
* Running format-code
* Manually resorting files in libqpdf/CMakeLists.txt
* Manually refilling the comment in QPDF.hh near class Resolver
On destruction of the QPDF object replace all indirect object references
with direct nulls.
Remove all existing code to release resolved references.
Fixes performance issue due to interaction of resetting QPDFValue::qpdf and
og members and prior code.
Also, modify QPDFObject::swapWith to update the ObjGens of the swapped
objects.
Modify QPDF::newIndirect and QPDF::updateCache to keep object ObjGens
up to date.
Also change QPDF::replaceObject and QPDF::swapObjects such that the
QPDFObject assigned to an og in the obj_cache is never replaced; only
QPDFObject::value is updated.
We need to know whether pushInheritedAttributesToPage or getAllPages
have been called when generating JSON output. When reading the JSON
back in, we have to call the same methods so that object numbers will
line up properly.
Where not possible, use "auto" to get the iterator type.
Editorial note: I have avoid this change for a long time because of
not wanting to make gratuitous changes to version history, which can
obscure when certain changes were made, but with having recently
touched every single file to apply automatic code formatting and with
making several broad changes to the API, I decided it was time to take
the plunge and get rid of the older (pre-C++11) verbose iterator
syntax. The new code is just easier to read and understand, and in
many cases, it will be more effecient as fewer temporary copies are
being made.
m-holger, if you're reading, you can see that I've finally come
around. :-)
Add comments to force line breaks, parenthesize function arguments
that are contatenated strings, etc. -- these kinds of changes improve
clang-format's results and also cause emacs cc-mode to match
clang-format. After this type of change, most of the time, when
clang-format and emacs disagree, clang-format is better.
This comment expands all tabs using an 8-character tab-width. You
should ignore this commit when using git blame or use git blame -w.
In the early days, I used to use tabs where possible for indentation,
since emacs did this automatically. In recent years, I have switched
to only using spaces, which means qpdf source code has been a mixture
of spaces and tabs. I have avoided cleaning this up because of not
wanting gratuitous whitespaces change to cloud the output of git
blame, but I changed my mind after discussing with users who view qpdf
source code in editors/IDEs that have other tab widths by default and
in light of the fact that I am planning to start applying automatic
code formatting soon.
