[ ... ]
Infinitesimal parts would not need to be stored in the object, they would be
part of the address, i.e., pointers would be longer.
First of all, that doesn't strike me as changing much except the name
you give to where you store it -- you're still creating a unique address
for each object, just like you do right now. Under some circumstances
you choose to ignore that difference, but it mostly seems to result in
complexity with little or no benefit.
It seems to me there's a much more straighforward method: nearly all
modern systems support virtual memory anyway. Simply allocate a chunk of
address space without any backing storage. Empty objects get allocated
addresses without backing storage. Everything involved is then supported
quite directly by typical hardware.
However, since
infinitesimal parts can be ignored most of the time, it is very likely that
the compiler could optimize away that overhead for almost all types within
any given program.
Which (more likely than not) results in even further complexity or even
more wasted space. For example, consider a situation where we cast from
a pointer to derived to pointer to base, then back to pointer to derived
(where the base is empty). In this case, we apparently need to add the
"infinitesimal" part to the pointer during the cast to base, then strip
it back off during the cast to derived -- or else we need to build in
intelligence elsewhere to deal with the fact that a pointer to base may
not always include an infinitesimal part, so everything that looks at a
pointer to base needs to start by figuring out what kind of pointer it's
dealing with.
Except in rather limited situations, this doesn't gain us anything
anyway -- we're changing the terminology from treating the stored data
as part of the object to treating it as part of the pointer, but we're
still stuck with the fact that we're storing some data for each object
we create. Worse still, that's data that really needs to be stored,
using up real memory, whereas simply assigning a new address to each
object can be done without using any real memory to back those
addresses. Worst of all, the amount of data we have to store will
generally exceed the amount we'd use up even if we had backing storage
for each object and assigned each its own address.
The one place I can see this as a possible gain is if we have addresses
with quite a few (at least 20 or so) address bits that are stored but
not used. That, however, almost always means a processor that supports
virtual memory anyway, so it would support the much simpler version I've
outlined above.