jimad@microsoft.UUCP (Jim ADCOCK) (08/07/90)
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.