Eventually consider padding for order of members in classes and structs

[Kurt Schwehr]

This is something I think we should consider for the long term for existing code and maybe worth thinking about when writing new. It's not something that I see evidence for an immediate need to focus on it.

Carefully layout of classes and structs can reduce the required padding. While it's small amounts, in each case, it can really add up over the size of a project. The trick is to do this in a way that focuses on the classes that typically have the most instances created and to not make the class harder to follow.

e.g. This may require as much as 7 bytes of padding for m_bBar for a 64-bit binary if pointers must be 8-byte aligned.

class Foo {
  void *m_pFoo;
  bool m_bBar;
  void *m_pBaz;
  bool m_bQux;
};

For data structures that have to be 16-byte aligned for some floating point ops, the situation is worse with up to 15-bytes of padding for a single member.

I'm not advocating for Bitfields unless there was extreme justification.

See also:

​http://www.catb.org/esr/structure-packing/

This change will be ABI incompatible for any public data members, so we need to be careful about if/when class public / protected members or structs are modified.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.