> > > the size of that member PdfVariant::m_eDataType was reduced to > 8 bits to save RAM space because PdfVariant objects are abundant > when using PoDoFo, not so much with the other ones you mention. > Therefore I don't agree with your proposal. The commit of my > change has made svn r1959 [1], btw. For the other enums this > could be discussed further, also with the other committers. > > There is actually enough space for 32-bit enum. Biggest data type of PdfVariant has 64 bits (m_Data) so alignof(PdfVariant) is 8 bytes and sizeof(PdfVariant) is multiple of 8 bytes (24 bytes currently). Align of m_Data is also 8. As PdfVariant has virtual members there is vtable pointer before m_Data occupying 8 bytes (on 32-bit architecture is padded by 4 unused bytes). Anything which is after m_Data will be also padded to multiple of 8 bytes. If m_eDataType would be changed to 32-bit enum then size of PdfVariant would be 32 bytes but if m_eDataType would be also moved right after m_Data or at the end of PdfVariant then size of PdfVariant would remain 24 bytes:
``` UVariant m_Data; /** Datatype of the variant. * required to access the correct member of * the union UVariant. */ EPdfDataType m_eDataType; bool m_bDirty; ///< Indicates if this object was modified after construction bool m_bImmutable; ///< Indicates if this object maybe modified // No touchy. Only for use by PdfVariant's internal tracking of the delayed // loading state. Use DelayedLoadDone() to test this if you need to. mutable bool m_bDelayedLoadDone; ``` > Best regards, mabri > > [1] https://sourceforge.net/p/podofo/code/1959/ > > Best regards, mabri > > > _______________________________________________ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users >
_______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users