On Monday, 20 February 2023 21:42:41 PST connor horman via Std-Proposals
wrote:
> The issue is that you get opted-into a `__declspec(dllimport)` whenever you
> use the standard library. At least some parts are linked via the MSVC C++
> Redistributable, IIRC.

You can choose to use a static runtime (/MT option instead of /MD and it's
actually the default). When you do that, all your libraries will be linked
together into your executable at the time link.exe is called. If any of the
.obj files provide a replacement operator new(size_t) or malloc symbol, it'll
be used.

The same exists for GCC and Clang, with the -static-libstdc++ option.

If you use dynamic runtimes, then the override will still apply to the
executable or library you're linking right now, but not to anything that
existed before you applied the override. It's entirely possible to have a set
of DLLs that find malloc or operator new in myproject.dll, without affecting
third-party, pre-existing DLLs. You just have to be careful about freeing
memory they allocated or their freeing memory you allocated. The simplest way
to accomplish this is to force all your C++ code to be linked with the
override and use only Win32 API to interface with the rest of the system.

> The operator new override should affect those parts as well, or the stdlib
> implementation is noncompliant.

It's perfectly compliant with the standards, because the standard does not
know anything about DLLs and runtime dynamic-linking. Within each DLL or the
executable, the standard requirements are met, as described above.

If there is a discrepancy, it will be the standard to change to allow for this
existing behaviour of 35+ years, which is not going to be changed. No amount
of standards-writing will get Microsoft to change such a core level
functionality of their OS.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering