Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ncar!elroy.jpl.nasa.gov!jarthur!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.std.c++ Subject: Re: "packed" objects Message-ID: <56288@microsoft.UUCP> Date: 3 Aug 90 18:55:37 GMT References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <6785@netxcom.DHL.COM> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 85 In article <6785@netxcom.DHL.COM> ewiles@netxcom.DHL.COM (Edwin Wiles) writes: >In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >>* Throw out the current C++ restrictions on field ordering entirely. What >>does it buy us anyway? Use 'extern "C"' where an object needs backwards >>compatibility to "C" packing order. >>* Require current field ordering restrictions be maintained on things declared >>"struct", but removed restrictions on anything declared "class." > >Let's see if I understand what you're proposing in the above two options. > >I get the idea that what you want is to have the compiler be able to >assemble the fields in the classes in any order, rather than strictly >in the order in which they were defined. Which *would* allow you to >pack bit fields together in the way you want, however.... Compilers already do not have to assemble the fields in the order they are defined. The basic present restriction is that within a labeled region [labeled by private: public: protected:] fields are to be placed at increasing addresses. The order in which various labeled regions are placed is compiler dependent. The spacing between those fields is compiler dependent -- one compiler might pack shorts on 2-byte boundaries, another might pack shorts on 4-byte boundaries -- representing two different compiler's choices of how they feel the tradeoff between speed and space should be handled. Also, where hidden fields [vtable pointers, virtual base pointers] are packed is also compiler dependent. Other issues in getting C++ compilers to be compatible are name mangling conventions, global ::new conventions, vtable agreements, calling conventions, optimization conventions,.... ...So I believe C++ compiler compatibility is outside the scope of the language. If a group of compilers are going to be compatible, their people are going to have to form some kind of consortium, and agree on hundreds of little nagging details. >I would argue against both of the above as a 'default' for the following >reasons: > > A) You would not be guaranteed that a data file written by a given > program on one machine, would be readable by the same program compiled > on a different machine under a different implementation of C++. > (Assuming that hardware and byte ordering are the same, the order > of structure/class elements wouldn't necessarily be the same.) This will not work today anyway -- for the reasons listed above. > B) Certain C++ languages (Lattice C++ for the Amiga for one) make > extensive use of C++ structures/classes to hide the cruft of working > with the system libraries. Surely a desireable end. However, the > system libraries depend on a specific order of elements within a > structure and would likely break under either of the above. Yes, I agree there is a need to have a way to maintain backwards compatibility with prior "C" libraries -- and their associated data structures. This is easily accomplished if a C++ compiler honors the 'extern "C"' to mean that C naming conventions are to be used, that C calling conventions are to be used, and that C packing conventions are to be used. Likewise 'extern "Pascal"' can be used where Pascal naming conventions are to be used, Pascal calling conventions, and Pascal packing conventions. >>* Introduce an explicit keyword "packed" or similar. Declaring a base class >>"packed" turns off field ordering restrictions in that class and its >>derivatives, as well as representing a directive to the compiler that small >>size is to be preferred to fast access. Possibly vtable ptrs could also >>be replaced with smaller type tags in such classes.... > >This would be more acceptable, as it leaves it as an option that the programmer >can use if appropriate, but doesn't force the issue. However, it could still >have the problems shown above, and should therefore NOT be used where >portability is important. If the structure/class is purely internal, never >appearing outside of the program in question, then it's acceptable. This is an argument relative to maintaining historical standards verses introducing innovative new techniques. Compilers can choose to be innovative, or they can choose to be conservative and maintain old packing standards. The marketplace can decide what compiler they like best. Or these choices can be handled via options. Likewise, many C++ compilers do not follow "C" calling conventions, but rather use Pascal calling conventions, or register passing conventions. The language does not dictate that C calling conventions continue to be used. Why should the language dictate even the minimal amount of packing order restrictions presently in place? What legal things can a programmer do to make use of the present packing order restrictions? Present packing order restrictions do almost nothing towards helping to C++ compilers be compatible. Nor do they help programmers. Lets get rid of the packing order restrictions.