Thank you for the explanation!

Am Dienstag, den 22.06.2021, 16:11 +0000 schrieb Billy O'Neal (VC LIBS):
>
> Moreover. the standard library on Windows is not an OS component; it is like any other library. We
> can be statically linked into as many DLLs as the user wants, and because no names are shared
> between DLLs they have no means of finding each other or similar. The average Windows process has
> at least 3 standard libraries inside it (the kernel one, the OS user one, the one the program
> uses). This is why you can use brand new C++2023 features on Windows Vista from 2006, because in
> the "ordinary deployment model" you bring your own CRT.

The C library has a very stable interface, so I wonder whether it
could be made a shared component distributed with the OS?

> > And does this imply that other state in the standard library is then also not shared between
> > different parts of a program?
>
> It does. If you pass, for example, a std::vector between DLLs that use different CRTs you are in
> undefined behavior land. (Where, in particular, debug features will end up using different locks
> since they are globals (!!!))
>
> The difference is that we consider std::atomic "like Core" and don't want to force customers using
> it to follow the usual "can't cross CRT boundaries" rules with it. Whereas atomic_ref only
> provides the usual guarantees: 2 DLLs that each statically link the CRT and use atomic_ref between
> them do not actually get atomic access for non-lockfree atomics.

For all external interfaces, it is intended that _Atomic(T)
is used (also for C++ compatibility).

It is then hopefully acceptable if the new atomic_ref-like
C feature (if we get it) would then have similar constraints
as atomic_ref in C++.

> > All the C-runtimes could maybe depend on yet another DLL to host the lock table (I think atomic-
> > ref does this?), but then you need to communicate to customers that they can't deploy
> > applications using this variety of atomics unless they distribute the extra DLLs, and put it in
> > system locations.
>
> We can't do that even if we wanted to because customers must be able to statically link. We take a
> dim view of applocal deployment sometimes but there are plenty of reasons customers can't use our
> redist installers sometimes, e.g. single binary xcopy deployment required scenarios.

There is no other way to setup some common shared
state between different C runtimes? Memory map a file at
a well known location?


Martin