🚀 go-pugleaf

Let me try to restate my original packing order question more clearly:

---
Should all vendors of all standard C++ compilers be prohibited for all time
from providing a standard C++ compiler that optimizes based on packing order?
If so, why?
---

People have posted many eloquent reasons why some vendor might want *not*
to offer such a compiler -- or might want a reason to allow packing to
be turned off:

I want my C++ compiler to be compatible with my C compiler.
I want my C++ compiler to work like I'm use to C compilers working.
I need predictable C++ lay-out order for operating systems work.
I want control over my C++ compiler.  I don't want it to control me.

That's fine.  There is nothing stopping a C++ compiler vendor from offering
a compiler to meet the needs of these people -- whether or not restrictions
on packing order are removed.  What the present C++ proposal *does* prevent is
for a vendor offering compilers to meet the needs of the following people:

I want my C++ compiler to generate the fastest and smallest code possible,
using the least amount of memory possible.  I want my C++ code to be as good
or better than any object oriented language now, or in the future.

Such a future compiler could do many things with packing order:

1) A derived class could fill the holes in a base class with some of its
members.

2) Partial bit fields could be shared with base classes.

3) Based on profiling data, the compiler could automatically [upon recompilationof a hierarchy] switch the ordering of two base classes withing an child class,
such that the more commonly used vtptr falls into slot 0 [typically resulting
in faster code.]

4) Based on profiling data, the compiler could automatically 
[upon recompilation] switch the ordering of fields in a region to move the 
more commonly used fields to the front.  Then, bus prefetch and on-chip 
caching would more likely allow access to the commonly-used fields faster, 
through better locality of reference.

5) etc, etc.


Frankly, I just don't see where forcing an ordering on the fields of region
helps anyone write legitimate [portable] C++ code.  What does it mean to be 
able to know the relative ordering of two things that *are not* elements of 
an array ??????

I want C++ compilers to be able to generate code as fast or faster than 
compilers for other OOPLs present or future.  This will not be the case
if C++ compilers must maintain backwards compatibility with non-portable 
C coding hacks.