On Tue, Feb 21, 2023 at 12:12 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.

While it is true that the standard does not know about DLLs, it also
doesn't *not* know about them.

That is, it defines the concept of a "program" as a set of translation
units linked together. Do translation units in a DLL count as part of
the same "program" as other TUs in other DLLs or exes? One could argue
that the TUs in a DLL count as part of the same program when it gets
used. But one could also argue that it isn't.

To me, the issue is that MSVC seems inconsistent on this. When it
comes to runtime type checking, the answer is "they are the same
program." You can use RTTI to engage with classes defined by a DLL
which were not directly exposed to your TU.

So it's strange that when it comes to global `new/delete` overloading,
the answer changes.

Also, what happens on non-Windows platforms if two different SOs
override the global `new` with different functions?

> 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.

It should also be noted that MSVC already has a few baked-in
violations of the standard since C++98 that they're just not going to
fix. For example, `struct` and `class` are supposed to be
interchangeable by the standard, allowing you to declare a name
`struct Name;` in one place and define it as `class Name {};`
elsewhere, with both referring to the same type. But MSVC requires
that you be consistent. And since this is part of the Windows ABI's
name mangling, and has been for decades, it's not going anywhere.

The idea that some ink on a page is going to cause the Windows ABI to
fundamentally change core parts of how stuff works on the platform is
a fantasy. If some part of the standard is changed in such a way as to
make implementation of that part highly impractical on their platform,
they *will not implement it.* Just like GCC took years to implement a
C++11-compliant `basic_string` because it was an ABI break for their
old COW-based string implementation.