🚀 go-pugleaf

In article <1316@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>In article <56843@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>+... {some things} make packing order compatibility a moot issue:
>...
>+Derived contiguous with parent structures, or references?
>
>I hope so.

Your hope is already not met on any C++ compiler that supports virtual
base classes.  The common derived-contiguous approach is fast and simple,
but has trouble with scheme evolution.  C++ compilers optimized towards
rapidly changing code, such as C++ interpreters, might do well to choose
a different layout scheme.

>+segmented or flat pointers?
>
>Everybody except Intel uses flat.  (No flames please.  All generalizations
>are false, including this one.)

It turns out that the 68000 reasonably supports segmented-like pointer
schemes, which get used a lot on the Mac to allow chunks of memory to
be easily moved.  So the two most popular computer families use segmentation,
at least some of the time.  Conversely, the Intel 386/486 etc, have 
perfectly good support for programming with 0:32 pointers.

My claim is that with OOP moving towards persistence, 0:32 pointers are
going to be a little small in a number of cases, and that people are 
going to start looking towards 16:32 or 32:32 pointers for these cases.
Segmenting can work well in these cases, with 0:32 pointers referring
to transient objects, and 16:32 or 32:32 pointers referring to persistent
objects.  One might argue that today's 0:32 machines will be reworked
into 0:48 or 0:64 machines, but I believe moving 0:32 machines to 16:32 or
32:32 segmented pointers would be more logical moves for the vendors of
those chips.

>+...  Thus, please leave compiler implementation
>+details out of the language specification. 
>
>One man's "implementation detail" is another man's language semantics.
>
>I believe that ANSI C requires that:
>
>	(&a[2] - &a[1]) == 1
>
>Are you going to suggest that this should have been left out of ANSI C
>because it unduly restricts the implementation of arrays to consecutive
>memory locations with ascending addresses?

No, because it easy to think of non-hack ways to use these features.
Iterating over arrays, comparing array addresses is common, and portable,
C and C++ usage.  However, iterating over structure elements, and comparing
structure element addresses within a structure, is not common, nor is it
portable.  Arrays are very different things from structures.

Note however, that on a machine like Rekursiv it may well be that the
actual objects in an array do not reside at consecutive addresses in
real memory.  This is fine, as long as programmers are presented with
a model where the standard array/pointer calculations still work.  One
solution might be to always make "an object" synonymous with a reference
to a chunk of memory.  Then the "sizeof" all objects is always the same
[probably either "1" or "4", depending on whether chars are handled just
like any other object]  Such an approach should work, and just maps C++
onto an object model more similar to other OOPLs, where "an object" is
always a reference to a chunk of memory, rather than the chunk of memory
itself.  Note that "sizeof" is not the same as the sum of the sizeofs the
elements of a structure, so that is not a constraint.

>How about the semantics of `volatile'?  Should that all be tossed out of
>ANSI C also?  After all, it does put some rather specific constraints on
>implementations.

I really don't care about ANSI-C.  I only have interests in C++.
I think volatile can have interesting, reasonable, usages, but I
see no reason why C++ usage of volatile need be identical to ANSI-C.
On the contrary, I'd be surprised if the needs of OOP don't force
some changes in the exact meaning of volatile.