🚀 go-pugleaf

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.