* Define it even though previous experiments have shown it to be
unnecessary since it seems like it may be necessary after all
* Add QPDF_DLL_CLASS to QPDFObjectHelper and QPDFDocumentHelper in
case there's some future unknown reason why someone may want to have
them and/or in case it helps with the weird
QPDFNameTreeObjectHelper problem.
This reverts commit 416d9668ee.
This commit causes numerous failures in the pikepdf test suite and
also causes a symbol to disappear from the public API. More
investigation will be required.
Removing an element from a set with iterator is constant time, and
std::set specifies that other operations on the set do not invalidate
existing iterators.
These markers are being added for nested classes that are already
marked with QPDF_DLL_CLASS. They don't make any different on Linux,
but they matter on Windows.
Replace operator== and operator!=, which were testing for the same
underlying object, with isSameObjectAs. This change was motivated by
the fact that pikepdf internally had its own operator== method for
QPDFObjectHandle that did structural comparison. I backed out qpdf's
operator== as a courtesy to pikepdf (in my own testing) but also
because I think people might naturally assume that operator== does a
structural comparison, and isSameObjectAs is clearer in its intent.
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.
