From 5c5b4e640e2df248192ff7aa518fb0d345884a33 Mon Sep 17 00:00:00 2001 From: Jay Berkenbilt Date: Thu, 6 Oct 2022 08:05:48 -0400 Subject: Be more conservative about QPDF_DLL_CLASS with mingw (fixes #799) * 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. --- README-maintainer | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'README-maintainer') diff --git a/README-maintainer b/README-maintainer index 545612c4..3658a347 100644 --- a/README-maintainer +++ b/README-maintainer @@ -179,9 +179,11 @@ CODING RULES the shared object boundary (or "shared library boundary" -- we may use either term in comments and documentation). In particular, anything new derived from Pipeline or InputSource should be marked - with QPDF_DLL_CLASS, but we don't need to do it for QPDFObjectHelper + with QPDF_DLL_CLASS. We shouldn't need to do it for QPDFObjectHelper or QPDFDocumentHelper subclasses since there's no reason to use - dynamic_cast with those. + dynamic_cast with those, but doing it anyway may help with some + strange cases for mingw or with some code generators that may + systematically do this for other reasons. IMPORTANT NOTE ABOUT QPDF_DLL_CLASS: On mingw, the vtable for a class with some virtual methods and no pure virtual methods seems -- cgit v1.2.3-54-g00ecf