id summary reporter owner description type status priority milestone component version severity resolution keywords cc 6588 Eventually consider padding for order of members in classes and structs Kurt Schwehr warmerdam "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. " enhancement closed low closed_because_of_github_migration default svn-trunk minor wontfix