CAlive will introduce pre and post blocks

[Rick C. Hodgin]

In an effort to augment existing software, and to better
document new software, and to allow a path to upgrade and
workaround existing implementation limitations that must
be dealt with for legacy purposes, CAlive will introduce
the ability to have pre { } and post { } blocks to code.

These can work on classes or structures, introducing new
storage to existing fixed structs which must pass through
legacy software in some way. And, they can be tagged to
any flow control / logic block to associate the code with
the block, but not fundamentally alter its operation. It
allows the prologue and epilogue code related to preparation
and clean- up to some block to be associated with it:

pre {
// Do some initialization here
// Allocate some things for the loop

} for (i = 0; i < 10; ++i) {
// Do the loop code

} post {
// Cleanup
}

Those three sections of code are now linked together for auto-
matic documentation purposes. Name the any of those blocks,
and an automatic outline is created.

-----
For classes or structs, it allows new fields to be added to
an existing design, to allow the new design to be passed and
referenced by its existing definition by legacy software that
does not know about its new features, and it allows the new
software that is aware of the new fields to use them as they
are silently passed through by allowing the extra data payload
to be transmitted using the traditional structure name.

For pointer math, using the standard ++ptr will cause it to
move forward / backward only by the sizeof(SWhatever), which
will cause it to fail if sequential data is stored using this
new format in a legacy app, but for single-instance pointers
that are transmitted through a legacy API and returned via a
callback, it will provide the larger payload unaware, while
maintaining the full original functionality.

The general format is:

// Traditional declaration
struct SWhatever
{
int c;
int d;
int e;
};

Assuming 32-bit integers, accesses are relative to the standard
SWhatever* ptr definition and natural address:

// With CAlive's pre and post declarations:
pre {
int a; // Accessed internally at at -8
int b; // Accessed internally at at -4

} struct SWhatever {
int c; // Accessed internally at at 0
int d; // Accessed internally at at 4
int e; // Accessed internally at at 8

} post {
int f; // Accessed internally at at 12
int g; // Accessed internally at at 16
int h; // Accessed internally at at 20
};

You can also use another syntax with labels (in any order,
and with multiple of each as needed):

struct SWhatever
{
pre:
int a;
int b;

data:
int c;
int d;
int e;

post:
int f;
int g;
int h;
};

When referencing sizeof(SWhatever), it shows only the size
of the three objects c, d, and e. When using either
presizeof(SWhatever) or postsizeof(SWhatever) it shows the
sizeof(SWhatever) plus the sizeof(SWhatever.pre) or the
sizeof(SWhatever.post).

If you need the new size of the entire structure, which
includes the pre and post blocks, then use allsizeof().
To allocate memory for an SWhatever structure, but using
the full pre/post block memory size, use allnew and the
alldelete to release it.

-----
For new pointer math, you can also use the underscore-bang
_! operator to move forward or backward from an "SWhatever*
ptr" declaration by the full quantity (including any pre/post
block bytes).

By placing the underscore before, and the bang after, it en-
capsulates the ptr variable, allowing pre- and post-blocks
to be navigated with pointer math:

SWhatever* ptr = allnew(SWhatever);

++ptr; // Would only skip forward by sizeof(SWhatever)
++_ptr!; // Skips forward by allsizeof(SWhatever)

alldelete ptr;

Mechanically, it's the equivalent of:

char* p = malloc(sizeof(SWhatever.pre) +
sizeof(SWhatever) +
sizeof(SWhatever.post));
SWhatever* ptr = (SWhatever*)(p + sizeof(SWhatever.pre));
// ptr now is pointing to the c member, and you could
// access data relative to it as needed into the pre and
// post block data areas.

--
Rick C. Hodgin

[Mr Flibble]

On 18/10/2018 01:39, Rick C. Hodgin wrote:
[terrible idea snipped]

What has this terrible idea got to do with C++ exactly?

/Flibble

--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."