>
>
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/podofo-users
>
_______________________________________________
Podofo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users
