More muddled thinking on my part. I started with one approach, then
mentally veered into another. If we're presuming multiple layers of
inheritance across more than two shared objects, the struct size of
each object needs to be available as a symbol as well. And I think
the offsets need to be chained.
And we probably need another untouchable struct defined per object.
And of course I should have been using size_t for all the offsets and sizes.
size_t __sizeof_Parent = sizeof(Parent);
struct __just_Child {
int result;
int subfield;
}
// symbols in shared object set to values at library compile time
size_t __Child_id = __Parent_id;
size_t __Child_type = __Parent_type;
size_t __Child_field = __Parent_field;
size_t __Child_order = __Parent_order;
size_t __Child_number = __sizeof_Parent + offsetof(struct __just_Child, number);
size_t __Child_subtype = __sizeof_Parent + offsetof(struct
__just_Child, subtype);
This then brings up packing and padding issues for the struct sizes,
but I'm hoping that this can be solved with appropriate attributes.
Speaking of attributes, I'm presuming that all these symbols for the
main lib will be "protected", so that access within the core won't be
as hindered.
Or perhaps we can simply the the macro act differently when in Core,
and behind the scenes convert to straight struct access.
Speaking of variants on the macro, I'm assuming that there will be
several compile time variants of the macro based on some defines.
Optimized but fragile for non-distributed binaries:
#define Child(self, var) self->var
Speedy but indirect as above:
#define Child(self, var) ( \\
(typeof( ((struct __Child *)0)->var)) \\
((char *) self + __Child_ ## var) \\
)
Debug with safety checks:
Add ISA() checks and anything else we can think of to either of the above.
----
I should mention that part of my confusion as to the need for this is
that I had been presuming that most people compiling their own
extensions would compile the library from source as well. And I
presumed that most people distributing extensions would distribute
source, whether for C or for an interpreted host language.
Could you explain the ecosystem you see existing? Is there a
comparable project that has a distribution style you'd like to
emulate? Just for Linux, I'd think it would be hard to do the
interchange between all minor variations: 32 vs 64 bit, glibc
versions, etc. How many would you envision, and how would the
extensions fit into this system?
--nate
