[Libreoffice-commits] core.git: editeng: Eliminate unecessary padding in classes

[Stephan Bergmann]

On 11/04/2015 12:03 PM, Norbert Thiebaud wrote:
> On Wed, Nov 4, 2015 at 4:53 AM, Stephan Bergmann <sbergman at redhat.com> wrote:
>>
>> What is sloppy about a set of members sorted due to some rationale?  (I do
>> not argue whether or not the members in this specific case were sorted due
>> to such a rationale.  I just want to avoid such random
>> micro-space-optimizations in the future to break well-founded orders.)
>
> how does one determine that there _is_ a well-founded order ?

That's why I suggested to leave it to people familiar with the code in 
question to decide whether and how to fiddle with "cosmetic" changes to 
member order.  (Where I consider padding-related changes to be cosmetic, 
unless there is a clear, documented benefit.)

One example that comes to mind is putting a mutex before the group of 
variables that it shall control access to.  (I routinely use such a 
member layout without any further documentation, assuming it to be 
sufficiently self-explanatory if the mutex-plus-controlled-members group 
is set off with empty lines around it.)

> imo intentional mis-alignment should be heavily documented as such.

I would assume "non-optimal" padding to occur frequently enough to just 
not care about it, unless there is indication that it severely affects 
performance.  Padding requirements can vary among platforms (e.g., due 
to differences in integer width types or differences in typedefs) and 
over time (e.g., when a member changes type or a member's type changes). 
  (And reordering members for tighter packaging can even negatively 
improve execution speed in various ways.)  So I would rather assume 
cases to be heavily documented where order is deliberately chosen to 
avoid padding.