The allocator is not the only part of the "environment" you might want to
pass down to a function; and Alisdair Meredith has been doing work on
allowing this. Calling conventions really aren't the problem.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2685r1.pdf is the
current attempt.

On Thu, Apr 18, 2024 at 2:32 PM Stephen Channell via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> The proposal is a half-way house between the current scheme where the heap
> has unchecked access and compiler-controlled pointers of Rust and C++ code
> analysis.
>
> It does so by standardizing Arena Allocators and adding a calling
> convention to pass a reference to the current threads arena.
>
>
>
> An example of Arena allocator is provided by google protobuf (
> https://protobuf.dev/reference/cpp/arenas/) with a similar allocator for
> LevelDB/derivations and apr_bucket for Apache httpd.
>
>
>
> Standardizing the different implementations of Arena allocation would be a
> worthy endeavor but does not justify the effort on its own but would for
> memory safety.
>
> arena alloc = make_unique<std::Arena>();
>
> would indicate that alloc is used as the default arena allocator while it
> remains in scope.
>
> std::Arena stored = arena;
>
> Would store the current arena for use by a std::allocator for collections
> that are part of a larger {session, singleton, configuration}.
>
>
>
> arenacall calling convention would extend the AMD64 ABI (where ‘this’ is
> the first parameter), with the arena as the second parameter, or thiscall
> convention (where ‘this’ is passed in register) with a register reserved
> for the arena. The arena would be either the current arena of the caller
> or ZERO to indicate that no arena is passed.
>
> arenacall functions for memory allocation and free would use the arena
> pointer for allocation and free if passed, and the CRT heap otherwise.
>
> void* __arenacall operator new (size_t size);
>
> void __arenacall operator delete (void* p);
>
> void __arenacall operator delete[] (void* p);
>
> void* __arenacall malloc(size_t
> <http://en.cppreference.com/w/cpp/types/size_t> size )
>
> void __arenacall free( void* ptr );
>
>
>
> · arenacall is suitable for scenarios where Rust might otherwise
> be considered, recognizing that Rust functions are normally called from
> C/C++, and call C/C++ foundation functions and cannot therefore guarantee
> safety.
>
> · arenacall is suitable for messaging services that would
> otherwise use a framework specific allocator or arena.
>
> · arenacall is suitable for scenarios where a system allows
> domain modules to be loaded but requires an elevated level of assurance
> that they cannot overwrite memory of other modules and do not leak memory.
>
> · arenacall would be faster for methods that allocate many
> temporary objects –saving heap calls may offset the cost of checked arena
> assertions.
>
> · arenacall embraces the C++ principle that you do not pay for
> options you do not choose to use.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>