On 9/3/21, Andrew Schepler <aschepler_at_[hidden]> wrote:
> Even the "simple" solution of adding a little data in the stack requires a
> breaking ABI change, which would be a big deal. It's also a violation of
> the C++ principle "you don't pay for what you don't use." I could see a
> compiler extension providing this for only functions specifically tagged
> with some attribute, if it were considered useful enough. From there to the
> Standard would be a harder step.
>
> But you can also get this behavior without extreme trouble just in the
> existing language. Define functions with that extra parameter, and use a
> callable class template object to wrap each with the wanted usage. A few
> preprocessor macros might help reduce the code for defining such a
> function.
>
> -- Andrew Schepler

Hi Andrew. I could do this with a stand-alone pre-processor. It
would just have to know enough C++ syntax to look for function
definitions and bodies, and then auto-inject those parameters.

As for existing C++, the ABI wouldn't break for functions that don't
reference the explicit and implicit parameters, meaning the entire
existing code base. For those, the ABI would generate as it always
has.

For new code that uses __ARGS_EXPLICIT__ and __ARGS_IMPLICIT__
references, only those would change the ABI. And they wouldn't
actually change the ABI. They would just inject two additional
parameters into the function calls, which are the explicit and
implicit counts, which are known at each instance where they are
issued.

If it were a new feature enabled in a specific version ... wouldn't it
work from that point forward? I know people like to have blind
accessibility to external libraries, but I think for this feature
there could be some new requirement that it not be blind.

Or, the compiler could auto-inject another function which could be
called which provides executive information about the function call /
ABI. It could be on a per-function basis, or a generic one which
provides feedback about the entire ABI as the compiler assigned it.

The caller could then query that ABI executive once at startup, and
then commit self-modifying code changes to allow for the variances.
1) No executive, assume it has no support for the explicit / implicit
count. 2) An executive, it specifies whether or not they're
required. And 3) self-contained code, the compiler + linker know
completely the entirety of the framework and ABI, and it could
self-accomodate.

-- 
Rick C. Hodgin