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."

[Rick C. Hodgin]

On Thursday, October 18, 2018 at 12:07:51 PM UTC-4, Mr Flibble wrote:
> On 18/10/2018 01:39, Rick C. Hodgin wrote:
> What has this terrible idea got to do with C++ exactly?

I believe you are significantly biased against me, Leigh. And
as such, if you don't already see the correlation, I doubt I'll
be able to explain it to you. But, here goes:

CAlive seeks to gain an audience from C and C++ developers since
it also has exception handling, the basic class, and features
familiar to C and C++ authors. What it does not have is the com-
plexity of C++. It essentially makes C a better C, introducing
a host of new features that others are welcome to take and incor-
porate into C or C++.

It is under development now and is slated for release in 2019 or
2020, preferably around Christmas 2019.

These posts are designed to spawn thought in individuals toward
new possibilities, and to get existing compiler authors to possibly
add those new features to existing compilers, and not necessarily
based on my ideas, but based on the thought which ensues helping
propel them to improve and increase their craft further.

> --
> [8 line signature snipped]

If you refer to this RFC 1855 document from October 1995:

Netiquette Guidelines
https://tools.ietf.org/html/rfc1855

And search for this portion, you'll find a reference to how long
signature line should be:

"If you include a signature keep it short. Rule of thumb
is no longer than 4 lines. Remember that many people pay
for connectivity by the minute, and the longer your message
is, the more they pay."

You seem to be an enforcer of netiquette, but are you also a hyp-
ocrite? Since you don't follow God and take your cues from Him,
do you just then glom on to whatever anti-Christ idea generates
in your own mind, and run with that as acceptable behavior? You
are essentially making an anti-God statement with every post,
and while it is in your signature line ... it's an ongoing state-
ment with regards to "religion" (from your point of view).

For someone who doesn't believe in God, you sure have a lot to
say about the subject. I wonder why?

The Bible speaks about people doing what's right in their own
eyes without regard to a higher authority:

https://www.biblegateway.com/passage/?search=Judges+17%3A6&version=KJV

6 In those days there was no king in Israel, but every man
did that which was right in his own eyes.

You have no unified King and are obeying what you feel is right
in your own eyes, Leigh. You are at war with others in the group,
as well as God. Such a position did not bode well for Israel at
any point in their history, and it will not bode well for you in
the end.

-----
Think about it, sir. You are better than complacency and ignor-
ance. You have an incredibly gifted mind and can rise above all
manner of falseness ... if you give yourself the opportunity.

--
Rick C. Hodgin

[Mr Flibble]

On 18/10/2018 18:09, Rick C. Hodgin wrote:
> On Thursday, October 18, 2018 at 12:07:51 PM UTC-4, Mr Flibble wrote:
>> On 18/10/2018 01:39, Rick C. Hodgin wrote:
>> What has this terrible idea got to do with C++ exactly?
>
> I believe you are significantly biased against me, Leigh. And
> as such, if you don't already see the correlation, I doubt I'll
> be able to explain it to you. But, here goes:
>
> CAlive seeks to gain an audience from C and C++ developers since
> it also has exception handling, the basic class, and features
> familiar to C and C++ authors. What it does not have is the com-
> plexity of C++. It essentially makes C a better C, introducing
> a host of new features that others are welcome to take and incor-
> porate into C or C++.

Just because you want C++ developers to see your folly it doesn't make it
on topic here as it has nothing to do with C++ and you are deluded if you
think any of its egregious features (such as the one this thread is about)
will make it into the C++ language.

[dross snipped]

[Rick C. Hodgin]

On Thursday, October 18, 2018 at 1:37:49 PM UTC-4, Mr Flibble wrote:
> ... your folly ... you are deluded ... egregious features ...

Well it's nice to know I was right ... you are significantly
biased against me. :-)

What happened to your GigaNews account? I thought you worked
out a deal with them to keep your account.

--
Rick C. Hodgin

[wyn...@gmail.com]

Rick C. Hodgin於 2018年10月18日星期四 UTC+8上午8時39分33秒寫道：

Something positive finally!

The pre{} for(;;) {} post {};

seemed useful in C, or create some useful cases people would like to see
not the impl. details.