> But there's still the issue where a user would like to use a more efficient
thread-local or allocation rate based allocator.

global operator new and delete can be replaced by a non inline, non static global operator new with equivalent signature; any uses of a new/delete expression (with equivalent signature) or direct call to operator new/delete from anywhere, including the standard library, will pick the user definition, no declaration of this replacement need to be in scope (ie, it is always implicitly visible, as would be the default implementation provided by the standard library).

See overloads 1-8 of operator new https://en.cppreference.com/w/cpp/memory/new/operator_new

overloads 1-12 of https://en.cppreference.com/w/cpp/memory/new/operator_delete

Note: As explained in the specification, providing a single replacement for `operator new(size_t)` and `operator `delete(void*)` is sufficient to cover all non alignment-aware overloads.

Julien V.

On February 20, 2023 12:20:57 p.m. EST, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Saturday, 18 February 2023 21:42:30 PST Phil Bouchard via Std-Proposals
>wrote:
>> But there's still the issue where a user would like to use a more efficient
>> thread-local or allocation rate based allocator.
>
>And what's stopping you and them from using a different allocator? You *can*
>replace malloc for your application. I do that for mine.
>
>Replacing it for already-compiled DLLs is a different story. But since DLLs are
>not part of the standard, its discussion is out of scope. The fact is that
>DLLs allow two functions called "malloc" to exist in two different DLLs and be
>called from another set of two different DLLs, without a problem[*], so long as
>one set doesn't try to free() pointers from the other. The C++ standard calls
>this "violation of the One Definition Rule".
>
>BTW, replacing malloc() is not a required part of the C or C++ standards. It's
>an extension to them that most toolchains support.
>
>[*] you usually don't want this, but it's *possible* by design.
>
>--
>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals