Hi
struct image
{
vec2 pos[2];
std::vector<vec3> pixels;
};
Now if any of those structs are modified, members added or removed, it would
require recompilation of the whole code that uses it. This is because the
memory offsets to access the fields change and might fall out of the
displacement range of the processor's instructions. So to support your idea
the compiler would need to generate worst-case code to access any arbitrary
offsets which will drag down code performance. The linker would need added
optimizing steps to undo this ... it sounds like a can of worms.
I believe that essentially refers to the inlining and optimization of
code accessing struct members.
My proposal is simple: "Why not compromise on that for once?"
C language enhances the relinkability of functions by compromising the
optimization of inline functions.
ELF2.0 enhances the relinkability of struct by compromising the
optimization of inline access to structure members.
