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