Topic: Packing Order Question Restated
Author: jimad@microsoft.UUCP (Jim ADCOCK)
Date: 6 Aug 90 23:09:37 GMT Raw View
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.